Maurice van der Pot posted <[EMAIL PROTECTED]>,
excerpted below, on Fri, 01 Jul 2005 20:35:36 +0200:
> If the point is to make dependencies complete, isn't there a way to
> build in some support for detecting it into some tool or other?
>
> If we have a program that can create an environment and
Chris Gianelloni posted <[EMAIL PROTECTED]>,
excerpted below, on Fri, 01 Jul 2005 18:01:43 -0400:
> Last time that I checked, each arch needs at least one non-cascaded
> profile, due to older versions of portage not working with cascaded
> profiles. Either this, or users will not be able to upgr
Caleb Tennis wrote:[Fri Jul 01 2005, 10:48:38AM EDT]
> On Friday 01 July 2005 08:56 am, Aron Griffis wrote:
> > How about this?
> >
> > ebuild:
> > DEPEND="some stuff"
> > qt_min_dep "3.3"
>
> How do you handle the ebuilds which use the qt use flag to determine whether
> or not that qt is
Dan Armak wrote:[Fri Jul 01 2005, 10:45:57AM EDT]
> Would work, but be against the general move to make the general ebuild
> section
> purely declarative :-(
Ok, but DEPEND="$(some-function)" is no more declarative. The
function is evaluated at the time that the ebuild is read, not later
when D
On Jul 1, 2005, at 5:59 PM, Drake Wyrm wrote:
Mike Frysinger <[EMAIL PROTECTED]> wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends
from
ebuilds- basically we rely on the profile to require a suitable
toolchain
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
> > Currently, we pretty much leave out the big dogs of build depends from
> > ebuilds- basically we rely on the profile to require a suitable
> > toolchain. Couple of issues with this though-
>
>
On Fri, 2005-07-01 at 23:48 +0200, Simon Stelling wrote:
> I've just removed a few deprecated profiles for amd64, and saw that
> there are still quite a lot of non-cascading profiles around.
> The following profiles say they have been removed by 2005.04.01:
>
> default-sparc-1.4
> defa
Hi all,
I've just removed a few deprecated profiles for amd64, and saw that
there are still quite a lot of non-cascading profiles around.
The following profiles say they have been removed by 2005.04.01:
default-sparc-1.4
default-sparc-2004.0
default-sparc64-1.4
def
On Thursday 30 June 2005 14:31, José Alberto Suárez López wrote:
> i think that all the ebook-* ebuilds must be removed. Is more easy to
> dowload the ebooks from the official web.
Sorry to reply to this just now but..
why don't try to use a script like the one Chris Write wrote for KDE themes?
Som
On Friday 01 July 2005 23:19, Paul de Vrieze wrote:
> On Friday 01 July 2005 17:14, Jonathan Smith wrote:
> > Thomas de Grenier de Latour wrote:
> > > Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> > >
> > > i've proposed? Using a return code seems to be the simplest way
> > > to
On Friday 01 July 2005 20:53, Diego 'Flameeyes' Pettenò wrote:
> On Friday 01 July 2005 20:42, Brian D. Harring wrote:
> > Err... missing the point, and proving my point. Current portage
> > _will_ fail because it's an unstated dependency. Why shouldn't
> > portage be provided the deps it needs s
On Friday 01 July 2005 17:14, Jonathan Smith wrote:
> Thomas de Grenier de Latour wrote:
> > Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> >
> > i've proposed? Using a return code seems to be the simplest way
> > to signal a failure, no?
>
> calling a function in a global scope
On Fri, Jul 01, 2005 at 02:12:07PM -0500, Brian D. Harring wrote:
> Best solution in my opinion for such a tool is abuse of binpkgs +
> chroot for testing, but that's beyond portage's focus, should be an
> external tool.
This is why I was only talking about build dependencies.
> A tool to do an
On Fri, Jul 01, 2005 at 08:56:45PM +0200, Maurice van der Pot wrote:
> On Fri, Jul 01, 2005 at 01:45:20PM -0500, Brian D. Harring wrote:
> > Not tenuable
> >
> > What you're effectivelly suggesting is that portage stomp ahead and,
> > hit a failure, try and figure out what atom would fix the fail
On Fri, Jul 01, 2005 at 08:53:18PM +0200, Diego 'Flameeyes' Pettenò wrote:
> On Friday 01 July 2005 20:42, Brian D. Harring wrote:
> > Err... missing the point, and proving my point. Current portage
> > _will_ fail because it's an unstated dependency. Why shouldn't
> > portage be provided the dep
On Fri, Jul 01, 2005 at 01:45:20PM -0500, Brian D. Harring wrote:
> Not tenuable
>
> What you're effectivelly suggesting is that portage stomp ahead and,
> hit a failure, try and figure out what atom would fix the failure,
> retry, wash rinse repeat.
No, I'm not talking about that. I'm talking
On Friday 01 July 2005 20:42, Brian D. Harring wrote:
> Err... missing the point, and proving my point. Current portage
> _will_ fail because it's an unstated dependency. Why shouldn't
> portage be provided the deps it needs so it can figure out what is
> needed to get to what the user requested?
> > > Full dependency information hasn't be viable due to resolver issues,
> > > which will be fixed.
> >
> > so why dont you come back once you have something that is supposed to work
> > ?
> > you're proposing we start generating a ton of circular dependencies which
> > we
> > arent even cl
On Fri, Jul 01, 2005 at 08:35:36PM +0200, Maurice van der Pot wrote:
> If the point is to make dependencies complete, isn't there a way to
> build in some support for detecting it into some tool or other?
>
> If we have a program that can create an environment and detect which
> programs are run w
On Fri, Jul 01, 2005 at 02:30:12PM -0400, Mike Frysinger wrote:
> On Friday 01 July 2005 02:11 pm, Brian D. Harring wrote:
> > Meanwhile, back to the "you want us to add what?", our dependency
> > graph *is* incomplete.
>
> so what ? i dont see it being a bug
I do. :)
We do a lot of work to hav
On Friday 01 July 2005 20:11, Brian D. Harring wrote:
> Regarding the "require whatever is used to uncompress the source",
> hadn't thought about it, but that _should_ be specified imo. That's
> also being a bit anal, but frankly, if the resolver can handle it, why
> shouldn't we specify the full
If the point is to make dependencies complete, isn't there a way to
build in some support for detecting it into some tool or other?
If we have a program that can create an environment and detect which
programs are run within the environment (maybe sandbox can do this,
maybe something with LD_PRELO
On Friday 01 July 2005 02:11 pm, Brian D. Harring wrote:
> Meanwhile, back to the "you want us to add what?", our dependency
> graph *is* incomplete.
so what ? i dont see it being a bug
> Something like 600 ebuilds in the tree state a
> dependency on gcc- we have 19000 ebuilds. Not all require
On Fri, Jul 01, 2005 at 01:49:19PM -0400, Mike Frysinger wrote:
> On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
> > Currently, we pretty much leave out the big dogs of build depends from
> > ebuilds- basically we rely on the profile to require a suitable
> > toolchain. Couple of issues
On Friday 01 July 2005 19:49, Mike Frysinger wrote:
> so what you're proposing is that we add binutils/gcc/glibc to every package
> that compiles something, make to every package that uses make,
> sed/grep/bash/coreutils to every package which runs configure, and
> tar/gzip/bzip2 to every package w
On Friday 01 July 2005 18:25, Brian D. Harring wrote:
> So... why don't we add a new DEPEND, BDEPEND (build depends), that
> holds atoms of what is required to actually build the package,
> literally, what executes on the box to build that package.
Ok trying to get this a bit more clean to tech peo
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
> Currently, we pretty much leave out the big dogs of build depends from
> ebuilds- basically we rely on the profile to require a suitable
> toolchain. Couple of issues with this though-
>
> 1) Deps aren't complete for an ebuild.
> 2) Mergin
Dan Armak wrote:
> Hi all,
>
> We finally have a stable-keyworded KDE 3.4.x. Enjoy :-)
>
ppc64 is stable, too! :-)
Markus
pgpzZv2lEkkce.pgp
Description: PGP signature
Hola.
Quick statement of terminology-
x-compile == cross compiling, building arm crap on an x86, building up
a x-compile target in a subdirectory of / (fex)
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
On Friday 01 July 2005 10:35 am, Alec Joseph Warner wrote:
>You don't force anyone to do anything. If they don't want to upgrade
> because they can't then they can p.mask the programs they can't upgrade.
But this isn't about upgrading Qt, it's about the packages that depend on it.
If you ch
Caleb Tennis wrote:
2. You'll force a user to upgrade to qt 3.3 if they attempt to install any
package that depends on Qt. Speaking from personal experience, I still have
some servers using Qt 3.1 because I have programs running 24/7 that rely on
Qt and simply cannot be upgraded right now.
On Friday 01 July 2005 18:03, Thomas de Grenier de Latour wrote:
> On Fri, 1 Jul 2005 17:45:57 +0300
>
> Dan Armak <[EMAIL PROTECTED]> wrote:
> > I'd rather signal failure to code outside the subshell by
> > touching a file in $T.
>
> The ${T} directory does not exists when portage source an ebuild
On Friday 01 July 2005 18:14, Jonathan Smith wrote:
> - gpg control packet
>
> Thomas de Grenier de Latour wrote:
> > Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> >
> > i've proposed? Using a return code seems to be the simplest way
> > to signal a failure, no?
>
> calling a fu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas de Grenier de Latour wrote:
> Btw, what's wrong with the `DEPEND="$(your_function)" || die`
> i've proposed? Using a return code seems to be the simplest way
> to signal a failure, no?
>
calling a function in a global scope is a bad idea. it
On Fri, 1 Jul 2005 17:45:57 +0300
Dan Armak <[EMAIL PROTECTED]> wrote:
>
> I'd rather signal failure to code outside the subshell by
> touching a file in $T.
>
The ${T} directory does not exists when portage source an ebuild
to get its metadatas, so I'm not sure that's a good idea.
Btw, what's
On Friday 01 July 2005 08:56 am, Aron Griffis wrote:
> How about this?
>
> ebuild:
> DEPEND="some stuff"
> qt_min_dep "3.3"
How do you handle the ebuilds which use the qt use flag to determine whether
or not that qt is a dependency?
Caleb
--
gentoo-dev@gentoo.org mailing list
On Friday 01 July 2005 16:56, Aron Griffis wrote:
> Dan Armak wrote: [Fri Jul 01 2005, 03:42:22AM EDT]
>
> > ...OK, so deprange() needs to signal errors out-of-band. Like setting a
> > KM_ERROR variable which causes the eclass to abort later on.
>
> Heh, doesn't work for the same reason you ca
Dan Armak wrote:[Fri Jul 01 2005, 03:42:22AM EDT]
> ...OK, so deprange() needs to signal errors out-of-band. Like setting a
> KM_ERROR variable which causes the eclass to abort later on.
Heh, doesn't work for the same reason you can't exit. It's
a subshell.
How about this?
ebuild:
Francesco R wrote:
[snip]
s/
># example:
>###MY_VER_RANGE 4.0 4.0.16
>###MY_VER_RANGE 4.1 4.1.4
>###MY_VER_RANGE 5.0
># if a patch contains these three lines then:
># all version >= 4.0 but < 4.0.16,
># all version >= 4.1 but < 4.0.16,
># all version >= 5.0 will be affected by this patch
>
>
/
e
Paul de Vrieze wrote:
>On Thursday 30 June 2005 23:11, Dan Armak wrote:
>
>
>>Instead of 'exit 1', qt_min_version should use die. I use that in
>>deprange and it does work inside $DEPEND.
>>
>>
>
>Wouldn't this be a good time to implement actual dependency ranges in
>portage. Btw. I normall
On Friday 01 July 2005 03:55 am, Chris Bainbridge wrote:
> > Why not just use =qt-3.3 since qt3 probably wont have any new major
> > release ?
>
> This would seem like the easiest option. Is there any reason not to do
> it this way?
Yes, two of them.
1. You don't know that there won't be a 3.4 qt
On Friday 01 July 2005 14:28, Dan Armak wrote:
> On Friday 01 July 2005 12:15, Paul de Vrieze wrote:
> > On Thursday 30 June 2005 23:11, Dan Armak wrote:
> > > Instead of 'exit 1', qt_min_version should use die. I use that in
> > > deprange and it does work inside $DEPEND.
> >
> > Wouldn't this be
On Friday 01 July 2005 11:55, Chris Bainbridge wrote:
> On 30/06/05, Olivier Crete <[EMAIL PROTECTED]> wrote:
> > On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote:
> > > I'm sorry, yes, that's what I do in this case.
> > >
> > > Also, the eclass is in portage if anyone is so inclined to see ho
On Friday 01 July 2005 12:15, Paul de Vrieze wrote:
> On Thursday 30 June 2005 23:11, Dan Armak wrote:
> > Instead of 'exit 1', qt_min_version should use die. I use that in
> > deprange and it does work inside $DEPEND.
>
> Wouldn't this be a good time to implement actual dependency ranges in
> port
On Thursday 30 June 2005 22:01, Thomas de Grenier de Latour wrote:
> On Thu, 30 Jun 2005 14:33:04 -0500
>
> Caleb Tennis <[EMAIL PROTECTED]> wrote:
> > $(qt_min_version 3.3) == "|| ( =x11-libs/qt-3.3.3
> > =x11-libs/qt-3.3.3-r1 =x11-libs/qt-3.3.3-r2
> > =x11-libs/qt-3.3.3-r3 =x11-libs/qt-3.3.4 )
>
On Thursday 30 June 2005 23:11, Dan Armak wrote:
>
> Instead of 'exit 1', qt_min_version should use die. I use that in
> deprange and it does work inside $DEPEND.
Wouldn't this be a good time to implement actual dependency ranges in
portage. Btw. I normally use the following hack that portage mig
On 30/06/05, Olivier Crete <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote:
> >
> > I'm sorry, yes, that's what I do in this case.
> >
> > Also, the eclass is in portage if anyone is so inclined to see how harmless
> > it
> > really i
>
> Why not just use =qt-3.
On Friday 01 July 2005 00:38, Aron Griffis wrote:
> Dan Armak wrote: [Thu Jun 30 2005, 05:11:10PM EDT]
>
> > Instead of 'exit 1', qt_min_version should use die. I use that in
> > deprange and it does work inside $DEPEND.
>
> Well, it's more visible, but it doesn't stop the emerge. I just put
48 matches
Mail list logo
