Re: [gentoo-dev] New developer: Brent Baude (ranger)
Tom Martin wrote: Hi list, Brent lives in Rochester, Minnesota, in the US. There he fills his days working for the IBM Corporation as a Team LEad and Linux Consultant, where his primary responsibility is to help people port hteir applications to Linux running on the IBM POWER4, POWER5, and JS20 platforms. While he does use Gentoo for his primary workstation and all his home boxes, Brent's interest in becoming a Gentoo developer is to help support the ppc64 and ppc archs for Gentoo. Of late, it's been in trying to whip the stage building and new livecds into shape. Brent is married and a father of two boys. When not working, he is an avid outdoors-man; specifically, he is most passionate about hunting pheasants, ducks and geese while training his two yellow Labrador Retrievers. Please say 'Hi' to Brent on IRC, and make him feel welcome. Regards, Tom Congrats ranger - good to have you on board. -- Omkhar Arasaratnam Gentoo PPC64 Developer [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New AT
On Fri, 2005-07-01 at 01:54 -0400, Joseph Jezak wrote: Now that I have minions (note the plural), it's time to take over the world! MUAHAHA. lol Congrats nixnut, and thanks hparker! :) No problem.. just don't work them /too/ hard ;) -- Homer Parker Gentoo/AMD64 Arch Tester Operational Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: qt.eclass
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 DEPEND=$(die) into an ebuild to test. Here is what happens. It also gives you an idea of why putting functions into DEPEND is bad: they get evaluated A LOT. (jump down for more message content) I see now that in my case, emerge aborted on die() due to a side effect: beta kchmviewer # emerge konqueror -pv These are the packages that I would merge, in order: Calculating dependencies waiting for lock on /dev/shm/aux_db_key_temp.portage_lockfile !!! ERROR: kde-base/konqueror-3.4.1 failed. !!! Function deprange-list, Line 426, Exitcode 0 !!! deprange(): unsupported parameters 1 2 - BASEVER must be identical !!! If you need support, post the topmost build error, NOT this status message. - !!! Problem in kde-base/konqueror dependencies. !!! too many values to unpack exceptions ...OK, so deprange() needs to signal errors out-of-band. Like setting a KM_ERROR variable which causes the eclass to abort later on. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpTRjWP1GFKs.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 might actually be made to understand: DEPEND=x11-libs/qt-4.0 !x11-libs/qt-3.2.1 Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpGK1foe2FfS.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 portage. Wouldn't any time be a good time? :-) Btw. I normally use the following hack that portage might actually be made to understand: DEPEND=x11-libs/qt-4.0 !x11-libs/qt-3.2.1 This depends on the fact that we don't actually have different-slotted versions of QT 3.2.1 in portage. If we still had eg qt 2.x, this would block it. So it's a temporary hack that'll only work for QT based on the fact that all qt 3.x versions have the same slot. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpbLY3fAf31a.pgp Description: PGP signature
Re: [gentoo-dev] RFC: qt.eclass
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 how harmless it really i 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? Sometimes we need to specify a minimal version or revision because something depends on specific fixes made there and needs to force a qt upgrade. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpX6M6iKO26J.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 a good time to implement actual dependency ranges in portage. Wouldn't any time be a good time? :-) Btw. I normally use the following hack that portage might actually be made to understand: DEPEND=x11-libs/qt-4.0 !x11-libs/qt-3.2.1 This depends on the fact that we don't actually have different-slotted versions of QT 3.2.1 in portage. If we still had eg qt 2.x, this would block it. So it's a temporary hack that'll only work for QT based on the fact that all qt 3.x versions have the same slot. I agree. What would be necessary is next to the || operator an operator that would select a single package that has both conditions, but that does not restrict what is installed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp4FUa4wgiZm.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 / example: ###MY_VER_RANGE [4.0,4.0.16) [4.1,4.1.4) [5.0,] # if a patch contains the previous line 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 / [snip] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: qt.eclass
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 can't exit. It's
a subshell.
How about this?
ebuild:
DEPEND=some stuff
qt_min_dep 3.3
eclass:
qt_min_dep() {
if cool; then
DEPEND=${DEPEND} new stuff
else
die ...
fi
}
Would work, but be against the general move to make the general ebuild section
purely declarative :-( I don't want to change a great deal of code merely to
catch incorrectly written ebuilds, when we can already print messages on
stderr.
I'd rather signal failure to code outside the subshell by touching a file in
$T.
--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpuioGFDf2I3.pgp
Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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
Re: [gentoo-dev] Re: RFC: qt.eclass
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 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?
--
TGL.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: qt.eclass
-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 leads to lots of unneccessary (and timely) computations remember your ebuild/end-of-mentoring quiz? - -- smithj Gentoo Developer [ desktop-misc netmon documentation ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCxV3Ml5AvwDPiUowRAhosAJ9IWOLs3Eknu3BB/NwkKyAGpx/W3gCfag0P dbjvgc97tDcrjHE5WSfLtiY= =XX8N -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: qt.eclass
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 function in a global scope is a bad idea. it leads to lots of unneccessary (and timely) computations Necessary in the case of kde split ebuilds. Take a look at kde-functions.eclass::deprange(). -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpY4Deq30kXt.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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
to get its metadatas, so I'm not sure that's a good idea.
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?
Sorry, I missed it the first time... Looks like a good way, yes (haven't
tested).
--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpw9chQK33m1.pgp
Description: PGP signature
Re: [gentoo-dev] RFC: qt.eclass
Caleb Tennis wrote: snip 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. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
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 change deps from =qt-3.0 to =qt-3.3 then nobody will be able to work with a Qt dependant package until they upgrade Qt. In the same regard, there are people still using Apache1 whom we aren't forcing to upgrade to Apache2 just so they can use some of the apache modules. Also, another downside to the =qt-3.3 approach is that it doesn't cleanly handle the cases of =qt-3.3.2-r1. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] splitting build deps out from depends
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 toolchain. Couple of issues with this though- 1) Deps aren't complete for an ebuild. 2) Merging a php or python lib that doesn't require compilation doesn't require a full toolchain, distutils/pear or make mainly. So autoassuming a c/c++ toolchain is required isn't accurate. 3) For automatically handling x-compile deps, without this info bound to an ebuild, portage will _never_ be able to know what dependencies are x-compile targets, and what deps must be natively merged. 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. Still would have DEPEND, since (using diffball as an example) building it doesn't execute anything from bzip2/libz, it just builds against those atoms. Aside from the goal of having complete dependencies, BDEPEND can be used by portage to know what needs to be built native to that box, vs what is an x-compiled dependency. So... we could actually do a full stategraph covering x-compile deps, and the actual x-compile toolchain. Thing is, it's an extra bit ebuild devs have to deal with. So get out your pitchforks/torches and throw in your two cents on the extra bit of effort required from ebuild devs. In the circles where this idea developed in, it solves some nasty portage issues (iow, it's useful to us for addressing a hard problem and supplying further functionality). Re: backwards compatibility, profile's holding the toolchain pretty much covers up the fact BDEPEND is missing from the tree; it's a non issue, only an issue if you're cross compiling (spanky's x-compile work mostly gets around this afaik, although it's something of abuse of portage), or if your profile doesn't specify a full toolchain. In other words, those who fall into the two scenarios above are already dealing with this issue, so there really isn't a concern of backwards compatibility. Either way, kindly chuck in your two cents (preferably on -dev ml, since this is cross posted). ~harring pgpwiFOdx4z4H.pgp Description: PGP signature
Re: [gentoo-dev] KDE 3.4.1 keyworded stable on x86, amd64
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
Re: [gentoo-dev] splitting build deps out from depends
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) Merging a php or python lib that doesn't require compilation doesn't require a full toolchain, distutils/pear or make mainly. So autoassuming a c/c++ toolchain is required isn't accurate. 3) For automatically handling x-compile deps, without this info bound to an ebuild, portage will _never_ be able to know what dependencies are x-compile targets, and what deps must be natively merged. 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 which has a gzipped/bzipped tarball in SRC_URI ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
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 people, we can outline this as: DEPEND - things which must be compiled for CTARGET BDEPEND - things which must be compiled for CHOST (as they are executed during the build process) -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpoujMgwfqvA.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 which has a gzipped/bzipped tarball in SRC_URI ? That's not dued to the adding of BDEPEND but more to the fact that deps are incomplete. I still don't like to add all the stuff we have in system in BDEPEND, but some strange deps are still needed to be there. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpXlrcg25mJB.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 with this though- 1) Deps aren't complete for an ebuild. 2) Merging a php or python lib that doesn't require compilation doesn't require a full toolchain, distutils/pear or make mainly. So autoassuming a c/c++ toolchain is required isn't accurate. 3) For automatically handling x-compile deps, without this info bound to an ebuild, portage will _never_ be able to know what dependencies are x-compile targets, and what deps must be natively merged. 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 which has a gzipped/bzipped tarball in SRC_URI ? Sort of, although I'd recommend a level of indirection. See jason's metapkg glep, if the package requires a c toolchain, BDEPEND=virtual/c-toolchain which is a metapkg expanding out to binutils/gcc/etc. Meanwhile, back to the you want us to add what?, our dependency graph *is* incomplete. Something like 600 ebuilds in the tree state a dependency on gcc- we have 19000 ebuilds. Not all requires gcc to build, but I'd bet it's a tad bit more then 600. Full dependency information hasn't be viable due to resolver issues, which will be fixed. 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 deps? Grouping/indirection obviously should be employed to mke the task easier, but the point stands. To head off the profile has it, so we don't need it, consider a user profile, literally, a user desktop profile. Kde, gnome, office crap, etc. Right now, for such a profile you would need the toolchain tagged in, which I posit is invalid. Give portage the data it needs, and it can map out what it needs to build up to the system definition. For the user profile example, if the user doesn't need it, why shouldn't an emerge depclean cleanse the tools that were merged to build packages? ~harring pgpfrZZIkmnwm.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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_PRELOAD, I'm sure we can think of something), then we can build a list of programs that are run during the build. If we have such a list, we can find out which packages are required to provide the tools in the list. Such a tool could be used to generate the correct build dependencies automatically or verify the existing bdeps. Maurice. -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpGC7GNwzY6q.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 deps? Then I'd like to see a way to define the decompression commands. That is: with bsdtar you can avoid having gzip, unzip, cpio around, as it extracts the files using libarchive (which then uses libz and libbz2 for those files), so you can extract tar, tgz, tbz2, tar.Z, cpio and zip archives (and iso files) with a single command. If it was possible, I'd like to use bsdtar for all them and remove cpio and unzip packages (gzip is still needed for other things). -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgp9oO6PLXpHy.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 have deps accurate, ignoring a fairly critical class of dependencies cause it's extra work seems a bit short sighted. Beyond that, see the user profile bit below, it shades incomplete toolchain dependencies as being a bug... Something like 600 ebuilds in the tree state a dependency on gcc- we have 19000 ebuilds. Not all requires gcc to build, but I'd bet it's a tad bit more then 600. and i continue to work day after day to make sure that 600 reaches 0 :p considering your system requires a virtual/libc in order to boot, tell me again why we must list it in every package which uses glibc ? 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 close to handling now Floating the idea. BDEPEND implementation (if people thought it was a good idea) would go alongside use/slot dep implementation. The short version is BDEPEND is fairly heavily related to domain work for collapsing config/ROOT into a single groupping portage can work with. No BDEPEND means that things are nastier for dealing with x-compile from portage's standpoint, so a general yay/nay on the concept is needed (hence it being raised now). 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 deps? portage could be smart about it ... it can easily parse the contents of SRC_URI and put tar into whatever DEPEND rather than forcing a stupid policy of listing tar in thousands of ebuilds Dep should be represented imo, regardless if portage automatically handles it (as mentioned above) or manually tacked in. Automatic tagging of such a dep makes a helluva lot more sense then manual. To head off the profile has it, so we don't need it, consider a user profile, literally, a user desktop profile. Kde, gnome, office crap, etc. Right now, for such a profile you would need the toolchain tagged in, which I posit is invalid. considering if you try to `emerge` something while under said profile and you already removed binutils/gcc from the system, the emerge will fail ... the reason why is pretty obvious 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? ~harring pgprEbffLvZOL.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 within the environment (maybe sandbox can do this, maybe something with LD_PRELOAD, I'm sure we can think of something), then we can build a list of programs that are run during the build. If we have such a list, we can find out which packages are required to provide the tools in the list. Such a tool could be used to generate the correct build dependencies automatically or verify the existing bdeps. 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. Short version is that what you're proposing is basically a set of tricks portage knows about to deal with failures; the problem is that these failures can manifest themselves in a lot of crazy ways. Aside from that, LD_PRELOAD style hacks aren't exactly easy to do on osx (got a dyld equiv, but have yet to see anyone do a sandbox equiv via it). ~harring pgpDuedBtMYXe.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 close to handling now Floating the idea. BDEPEND implementation (if people thought it was a good idea) would go alongside use/slot dep implementation. The short version is BDEPEND is fairly heavily related to domain work for collapsing config/ROOT into a single groupping portage can work with. No BDEPEND means that things are nastier for dealing with x-compile from portage's standpoint, so a general yay/nay on the concept is needed (hence it being raised now). Addendum to this; no cycles are induced, cause portage (current versions) don't know about BDEPEND, and won't know about bdepend until a resolver is in place that can handle it. So... forget about pissing off current portage, this is looking forward a bit. ~harring pgptZE5RiHZMj.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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? BDEPEND is not going to resolve the case Mike shown. GCC bdepends over GCC to compile, you don't have GCC, you can't install GCC, you can't install anything (a part from binpkgs). But if you put GCC in profile, no need to depend on it, you'll always have one also if nothign depends on it and the problem is resolved. BTW, as I already stated on irc, GCC is a RDEPEND not a BDEPENED because of libgcc_s.so and libstdc++.so, so... -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpcUUFOQjKpu.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 about something to help an ebuild writer. If I'm emerging my newly written ebuild and it works, I still may have missed a few build dependencies. This situation would probably result in a lot of ebuilds with incomplete build dependencies and a lot of work for the cross-compiling people. By using a tool like I described, I can see what I still need to add to the list. Maurice. -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpJrVByzP8he.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 deps it needs so it can figure out what is needed to get to what the user requested? BDEPEND is not going to resolve the case Mike shown. GCC bdepends over GCC to compile, you don't have GCC, you can't install GCC, you can't install anything (a part from binpkgs). But if you put GCC in profile, no need to depend on it, you'll always have one also if nothign depends on it and the problem is resolved. BTW, as I already stated on irc, GCC is a RDEPEND not a BDEPENED because of libgcc_s.so and libstdc++.so, so... Bleh, aparently I missed the point of his example- the depclean bit would apply for yanking packages that aren't needed, make and friends for example. Holding onto unwind/stdc++/gcc_s (gcc[-nocxx]) is another beast, which still not sure about addressing aside from the hated RDEPEND=virtual/libc. Addressing earler question of why virtual/libc should actually be rdep'ed (and mike's example), figure it thus, the only thing that's keeping portage from wiping it on a depclean run is that it's in the profile. Corrupt your profile, portage _will_ wipe it because the depgraph isn't complete. The response to that I'm sure is well don't corrupt your profile, but one thing to note is that it implicitly forces requiring a valid profile. Thing is, you're forcing the requirement of the profile, and that it specify information that keeps portage from doing stupid things. There's no valid reason that portage management of a system must rely on the profile as a crutch to keep it from doing stupid things, when specifying *full* dependencies removes teh crutch, and gives portage the knowledge it needs to do other crazy crap that is desirable. ~harring pgpl35qT3eYRK.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 failure, retry, wash rinse repeat. No, I'm not talking about that. I'm talking about something to help an ebuild writer. If I'm emerging my newly written ebuild and it works, I still may have missed a few build dependencies. This situation would probably result in a lot of ebuilds with incomplete build dependencies and a lot of work for the cross-compiling people. By using a tool like I described, I can see what I still need to add to the list. 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. A tool to do analysis of a package/ebuild and discern the BDEPEND's I could see, just thought you were suggesting it be defacto on the fly thing :) ~harring pgpwV792HyKXy.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 analysis of a package/ebuild and discern the BDEPEND's I could see, just thought you were suggesting it be defacto on the fly thing :) I'll try not to be offended ;) Maurice. -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpguNvVqjQ6e.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 is a bad idea. it leads to lots of unneccessary (and timely) computations It also makes any attempts to parse ebuilds without using bash (our current strategy) a lot harder (actually causing bash reimplementation) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpUtMdsW3iQp.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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 so it can figure out what is needed to get to what the user requested? BDEPEND is not going to resolve the case Mike shown. GCC bdepends over GCC to compile, you don't have GCC, you can't install GCC, you can't install anything (a part from binpkgs). But if you put GCC in profile, no need to depend on it, you'll always have one also if nothign depends on it and the problem is resolved. BTW, as I already stated on irc, GCC is a RDEPEND not a BDEPENED because of libgcc_s.so and libstdc++.so, so... No, it's both. You need to have a cross gcc on the compiling machine, and a runtime gcc (gcc-lib parts) on the running machine. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpmvciRn55lv.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 signal a failure, no? calling a function in a global scope is a bad idea. it leads to lots of unneccessary (and timely) computations It also makes any attempts to parse ebuilds without using bash (our current strategy) a lot harder (actually causing bash reimplementation) You mean you're actually doing that for portage-cvs? I didn't know that. Does 'our current strategy' refer to using bash or to not using it? Anyway, as far as portage goes, if we had version range deps support we wouldn't need functions in $DEPEND. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpYA48zJK20i.pgp Description: PGP signature
Re: [gentoo-dev] remove app-doc/ebook-*
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? Something users can use to install the ebook downloaded from the net without need to have the ebuilds in portage, still using the ebook eclass. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpU701bt1UQx.pgp Description: PGP signature
[gentoo-dev] profiles cleanup
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 default-sparc64-2004.0 I hope this is not an April Fool's joke ;) There are also many other profiles which are probably deprecated for ages, but don't contain an information about when they will be taken out of portage. Other possible candidates for a clean-up: default-alpha-1.4 default-alpha-2004.0 default-ppc-1.4 default-ppc-2004.0 default-ppc-2004.1 default-ppc-2004.2 default-ppc64-2004.2 default-x86-2004.2 gcc33-sparc64-1.4 hardened-x86-2004.0 I didn't check them all, so I may be wrong, but some of them are deprecated for over a year now. There are also some cascading profiles which are really old and probably should be removed. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] profiles cleanup
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 default-sparc-2004.0 default-sparc64-1.4 default-sparc64-2004.0 I hope this is not an April Fool's joke ;) There are also many other profiles which are probably deprecated for ages, but don't contain an information about when they will be taken out of portage. Other possible candidates for a clean-up: default-alpha-1.4 default-alpha-2004.0 default-ppc-1.4 default-ppc-2004.0 default-ppc-2004.1 default-ppc-2004.2 default-ppc64-2004.2 default-x86-2004.2 gcc33-sparc64-1.4 hardened-x86-2004.0 I didn't check them all, so I may be wrong, but some of them are deprecated for over a year now. There are also some cascading profiles which are really old and probably should be removed. 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 upgrade from old installations that have not been upgraded for some time. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splitting build deps out from depends
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-
so what you're proposing is that we add binutils/gcc/glibc to every package
that compiles something
Can you compile without binutils/gcc/glibc? No? Then you need it.
make to every package that uses make,
Again, if you depend on make, then DEPEND on make.
sed/grep/bash/coreutils to every package which runs configure
That's quite an interesting case. Yes, those should be in DEPEND, but it
might be prudent to create an appropriate shortcut instead of explicitly
adding each of those.
Three possibilities come to mind.
0) For ebuilds which use the standard GNU autoconf-generated configure
script, a standard set of tools could be added to DEPEND from a
standard variable.
DEPEND=${ac-configure} dev-libs/libwombat app-misc/imanotherdep
where ${ac-configure} expands to everything that runs in yer typical
configure script.
1) Use the eclasses. Right before inheriting eutils, provide a token to
tell eutils to add some appropriate DEPEND tokens.
ac-configure=yup
inherit eutils
Many of the eclasses add a few DEPEND tokens. Use the standard
eclass(es) to add the standard DEPENDs.
2) Well, maybe cramming this into eutils isn't such a hot idea, but
creating an eclass for the purpose of adding the generic dependencies
would work better.
edeps=configure make c-tools
inherit edeps
tar/gzip/bzip2 to every package which has a gzipped/bzipped tarball in
SRC_URI ?
Now this could _definitely_ play into suggestion (2) above. Have the
edeps eclass check the SRC_URI and add the appropriate unpacking
packages.
edeps=make
SRC_URI=http://www.wombats.com/i_need_tar_and_bzip2.tar.bz2;
inherit edeps
Whee.
rant class=flame
I know this will be shot down, as it has been shot down each time in the
past that somebody has suggested it. I wish it were not the case. Almost
every ebuild in the tree fails to completely and accurately reflect its
dependencies. The fact that this is somehow a technical decision leads
me to suspect that more of Portage is also horribly broken.
/rant
--
Batou: Hey, Major... You ever hear of human rights?
Kusanagi: I understand the concept, but I've never seen it in action.
--Ghost in the Shell
pgppm50RcpeF1.pgp
Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
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. Couple of issues with this though-
so what you're proposing is that we add binutils/gcc/glibc to
every package
that compiles something
Can you compile without binutils/gcc/glibc? No? Then you need it.
make to every package that uses make,
Again, if you depend on make, then DEPEND on make.
sed/grep/bash/coreutils to every package which runs configure
That's quite an interesting case. Yes, those should be in DEPEND,
but it
might be prudent to create an appropriate shortcut instead of
explicitly
adding each of those.
Three possibilities come to mind.
0) For ebuilds which use the standard GNU autoconf-generated configure
script, a standard set of tools could be added to DEPEND from a
standard variable.
DEPEND=${ac-configure} dev-libs/libwombat app-misc/
imanotherdep
where ${ac-configure} expands to everything that runs in yer
typical
configure script.
1) Use the eclasses. Right before inheriting eutils, provide a
token to
tell eutils to add some appropriate DEPEND tokens.
ac-configure=yup
inherit eutils
Many of the eclasses add a few DEPEND tokens. Use the standard
eclass(es) to add the standard DEPENDs.
2) Well, maybe cramming this into eutils isn't such a hot idea, but
creating an eclass for the purpose of adding the generic
dependencies
would work better.
edeps=configure make c-tools
inherit edeps
tar/gzip/bzip2 to every package which has a gzipped/bzipped
tarball in
SRC_URI ?
Now this could _definitely_ play into suggestion (2) above. Have the
edeps eclass check the SRC_URI and add the appropriate unpacking
packages.
edeps=make
SRC_URI=http://www.wombats.com/i_need_tar_and_bzip2.tar.bz2;
inherit edeps
Whee.
rant class=flame
I know this will be shot down, as it has been shot down each time
in the
past that somebody has suggested it. I wish it were not the case.
Almost
every ebuild in the tree fails to completely and accurately reflect
its
dependencies. The fact that this is somehow a technical decision leads
me to suspect that more of Portage is also horribly broken.
/rant
Well, {humans,monkeys,ebuild maintainers} can't be trusted to
accurately track a packages dependencies, be it build or runtime. The
way some other build systems deal with this is keeping a table
mapping files to packages, and simply monitoring every file touched
during compilation and runtime to generate deps.
Accurate deps should be a goal for the tree, a long term one
obviously...
Kito
--
Batou: Hey, Major... You ever hear of human rights?
Kusanagi: I understand the concept, but I've never seen it in action.
--Ghost in the Shell
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: qt.eclass
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 DEPEND is processed. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgplQXYUI4PWe.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
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 a dependency? Bah, good point. I knew it was too easy. :-) It seems like at this point there is one good suggestion on the table for an immediate fix: DEPEND=... || die Of course we all want more flexible DEPEND processing in portage, but another avenue of research for somebody is to read the ebuilds (not necessarily execute the functions) with set -e. That doesn't solve the problem quickly enough for you, since it requires a portage change, but it would solve the general problem of calling functions from strings (so long as you only call one!) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpOnRcudN3AM.pgp Description: PGP signature
[gentoo-dev] Re: profiles cleanup
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 upgrade from old installations that have not been upgraded for some time. IIRC (because I made a similar argument, tho likely not as well) when this came up the last time, the decision was to create a rescue site with one such profile per arch, getting them out of the tree and uncluttering it. Either that, or combine it with the rescue portage project, such that they can download and untar a functionally usable cascade understanding portage version to get them out of between the rock and the hard place, using the same functionality now in place for when portage itself crashes. This alternative may actually already be in place only we hadn't thought about it. The idea being... If someone has been offline for two years or whatever, it's really sort of unreasonable for them to expect a problem free upgrade in the first place. They can post a question on the lists or forums or irc, and be directed to the proper location and procedure as necessary. Alternatively, and /not/ that much less practically if you think about it anyway, given the number of packages they'll have to update if they've been offline for well over a year, they can simply download the latest LiveCD and start over with a clean install, even stage-3 plus GRP, if they are impatient, and be caught-up with far less hassle than attempting to do it in-place, starting from such an old snapshot that there's been no testing nor real consideration of the upgrade path in the first place, thereby creating far more hassle than necessary for themselves, getting everything working. IOW, just as Gentoo as it exists today isn't really suitable for nor does it support the multi-year freeze-frame snapshots plus security-only update routine of strict enterprise policy, because that simply doesn't fit the continual update community focused distribution model Gentoo has chosen, so a similarly outdated offline for two years Gentoo installation cannot be expected to be able to update as if it were last updated a week ago. The Gentoo model does not support such, nor, without dividing scarce developer resources, can it be made to do so, regardless of whether those last non-cascading profiles remain in place or not. The rescue portage may well work, but even then, there will be other issues. If it's been a year, chances are a from-latest-stage-X upgrade will be about even hassle compared to an upgrade in place. If it's been a year and a half, things favor the from-stage-X upgrade. If it's been two years or longer, things VASTLY favor the from-stage-X upgrade. That's just the way it is, with Gentoo as it exists today. If it's not the profiles causing the issue, it'll be some other incompatibility causing headaches, and whether or not they can be overcome, from-stage-X is simply going to be less of an issue, and be easier to support, because others will have likely run into similar problems, so the answers will be easier to find. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: splitting build deps out from depends
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 detect which programs are run within the environment (maybe sandbox can do this, maybe something with LD_PRELOAD, I'm sure we can think of something), then we can build a list of programs that are run during the build. If we have such a list, we can find out which packages are required to provide the tools in the list. Such a tool could be used to generate the correct build dependencies automatically or verify the existing bdeps. If the other subthread touched on this, I missed it. Just because an executable may be used if there, doesn't necessarily make it a depend. Such a tool will document the path to configuration and compilation used in the particular case of the system at the time it was run, but many of those dependencies are one of several options (could be handled by virtuals, tho such would have to be hashed out and added to a list that said tool uses over time, and then we have the issue of making the tool smart enough to know when the virtual is required, vs. when a specific instance of that virtual is required) or are only used if present, with another path entirely taken if not. It might be possible to create a tool that could help automate /some/ of this, but getting it all right even a simple majority of the time would be very challenging and complex. Basically, to get it right, you'll have to have a human skilled in that sort of thing parse the output and match it against the actual package behavior, anyway. Thus, in ordered to have any sort of consistency, the requirement would be an entire team of devs doing little else but verifying this information, since many ebuild maintainers would be as out of their depth as someone who's only worked on x86 scripting all their life would be with ppc64 bitness AND endianness issues. That's a LOT of developer infrastructure we are talking about creating and supporting, and a LOT of developer resources that therefore won't be available for other things, when developer resource shortages /already/ exist. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-portage-dev] splitting build deps out from depends
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 toolchain. Couple of issues with this though- 1) Deps aren't complete for an ebuild. 2) Merging a php or python lib that doesn't require compilation doesn't require a full toolchain, distutils/pear or make mainly. So autoassuming a c/c++ toolchain is required isn't accurate. 3) For automatically handling x-compile deps, without this info bound to an ebuild, portage will _never_ be able to know what dependencies are x-compile targets, and what deps must be natively merged. 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. Still would have DEPEND, since (using diffball as an example) building it doesn't execute anything from bzip2/libz, it just builds against those atoms. Aside from the goal of having complete dependencies, BDEPEND can be used by portage to know what needs to be built native to that box, vs what is an x-compiled dependency. So... we could actually do a full stategraph covering x-compile deps, and the actual x-compile toolchain. Thing is, it's an extra bit ebuild devs have to deal with. So get out your pitchforks/torches and throw in your two cents on the extra bit of effort required from ebuild devs. In the circles where this idea developed in, it solves some nasty portage issues (iow, it's useful to us for addressing a hard problem and supplying further functionality). Re: backwards compatibility, profile's holding the toolchain pretty much covers up the fact BDEPEND is missing from the tree; it's a non issue, only an issue if you're cross compiling (spanky's x-compile work mostly gets around this afaik, although it's something of abuse of portage), or if your profile doesn't specify a full toolchain. In other words, those who fall into the two scenarios above are already dealing with this issue, so there really isn't a concern of backwards compatibility. Either way, kindly chuck in your two cents (preferably on -dev ml, since this is cross posted). ~harring pgpq2H1iWG2bn.pgp Description: PGP signature
