[gentoo-dev] splitting build deps out from depends

[gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Mike Frysinger]

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

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)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

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)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 2566 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Mike Frysinger]

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 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

> 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

> 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
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Maurice van der Pot]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

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   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

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)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

> > > 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

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)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Maurice van der Pot]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

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   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Maurice van der Pot]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

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   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Drake Wyrm]

[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Kito]

On Jul 1, 2005, at 5:59 PM, Drake Wyrm wrote:

> Mike Frysinger <vapier@gentoo.org> 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

[gentoo-dev] Re: splitting build deps out from depends

[Duncan]

Maurice van der Pot posted <20050701183536.GR19598@kfk4ever.com>,
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

Re: [gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]

On Fri, Jul 01, 2005 at 08:16:46PM -0500, Kito wrote:
> Accurate deps should be a goal for the tree, a long term one  
> obviously...
Picking at the words (not you), but "long term" == it gets ignored 
till someone starts screaming/foaming at the mouth.

If BDEPEND were added, it's extra data that next version of 
portage could use to do crazy stuff, and it wouldn't screw up existing 
portage in anyway.

What crazy stuff?  Aside from having _full_ deps so we can trust 
portage not to do something stupid if the profile is missing, BDEPEND 
provides classification of a set of atoms that must be native to a 
system.

Since there is a seperation of what is effectively chost (bdepend) and 
ctarget (depend), you're giving portage a classification of depends 
for a package that it can use to do (what I'm calling) interdomain 
deps.

In other words for an arm x-compile target's BDEPENDs can be mapped 
back to the native host of the box.  It allows the possibility for 
portage to natively support x-compile.

Without it, it's not possible natively in portage, nor is the solution 
totally clean (imo at least).

So... getting back to the long term bit, input in the here and now as 
to why this will never be implemented is required.  Just to point out 
a bit again, the metapkg proposal will allow grouping of 
arbitrary atoms, so a virtual/c-toolchain could be used to collapse 
binutils/glibc/etc down to a single atom (indirection rocks, no? :)
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 4597 bytes --]

On Fri, 2005-07-01 at 13:42 -0500, Brian D. Harring wrote:
> 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. :)
> 

I don't as well, until you can prove that portage can handle a system
install without a system profile, and everything depending on the system
profile.

Just an example what an 'innocent' fix can do by adding a system profile
item somewhere into an DEPEND where it does not belong, see bug #96209.

> 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).
> 

Like every other idea, it might be nice - just as the
multi-slot-per-version idea would have been cool for x-compiling ... but
still are not implemented.

Do not get me wrong .. I assume this will do wonders for x-compiling and
prevent world war, etc, but as Linus (or some other guy) would say:
Show me the Code.

On another note .. how do you guys plan to handle this BDEPEND .. just
for x-compile, or global?  If global, any ideas how to solve the
circular issues ???

> 
> > > 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.
> 

True, but its not always viable .. how much longer will it take portage
to compute a dep graph that is 200 times more complete? 2 times? 10?
Also as already asked, what about the chicken egg issue ... (think tar
needing tar, or gzip needing gzip to unpack)?

> > > 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?
> 

I do not think so .. his point is: htf do you build binutils without
binutils installed ?  Same for gcc.


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote:
> Mike Frysinger <vapier@gentoo.org> 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.
> 

This is all well and dandy, but try to add coreutils as a dependency of
itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
a stage1 install (probably stage2/3 as well, but I never do those, so
rather wont comment).

The point that Mike and I make, is that portage cannot handle this (and
probably wont be able to in future without a _lot_ of black magic), and
this is why we need the system profile which have just the right amount
of DEPEND magic to make it work, and then everything else depends
automagically on the system profile (and everything in it).  Making the
adding of system packages to non system packages really redundant.

Sure it might be fixable, but the only way I see how, is to have a
complete system profile (with all the dependencies that are currently
lacking), and then

  # emerge --oneshot --nodeps $(cat /some/path/system-profile)

But this gets to the verge of being too static, having the effect that
some optional dependencies for the system profile cannot be used. (There
are probably other ways, but this is the first that I could think of,
and more as an example ...)


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Brian Jackson]

Martin Schlemmer wrote:
> On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote:
> 
>>Mike Frysinger <vapier@gentoo.org> 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.
>>
> 
> 
> This is all well and dandy, but try to add coreutils as a dependency of
> itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
> a stage1 install (probably stage2/3 as well, but I never do those, so
> rather wont comment).

Big picture here:
* BDEPEND does nothing now, so don't worry about it if you don't want to
* in the future it will make other things possible
* give the man problems you see with the proposal, not just tell him that 
portage doesn't handle it right now... I think out of anyone, he knows what 
portage does and doesn't handle

--Iggy

> 
> The point that Mike and I make, is that portage cannot handle this (and
> probably wont be able to in future without a _lot_ of black magic), and
> this is why we need the system profile which have just the right amount
> of DEPEND magic to make it work, and then everything else depends
> automagically on the system profile (and everything in it).  Making the
> adding of system packages to non system packages really redundant.
> 
> Sure it might be fixable, but the only way I see how, is to have a
> complete system profile (with all the dependencies that are currently
> lacking), and then
> 
>   # emerge --oneshot --nodeps $(cat /some/path/system-profile)
> 
> But this gets to the verge of being too static, having the effect that
> some optional dependencies for the system profile cannot be used. (There
> are probably other ways, but this is the first that I could think of,
> and more as an example ...)
> 
> 
> Thanks,
> 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

On Tue, 2005-07-05 at 18:17 -0500, Brian Jackson wrote:
> Martin Schlemmer wrote:
> > On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote:
> > 
> >>Mike Frysinger <vapier@gentoo.org> 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.
> >>
> > 
> > 
> > This is all well and dandy, but try to add coreutils as a dependency of
> > itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
> > a stage1 install (probably stage2/3 as well, but I never do those, so
> > rather wont comment).
> 
> Big picture here:
> * BDEPEND does nothing now, so don't worry about it if you don't want to
> * in the future it will make other things possible
> * give the man problems you see with the proposal, not just tell him that 
> portage doesn't handle it right now... I think out of anyone, he knows what 
> portage does and doesn't handle
> 

I did ask Brian in another reply how he thought to implement it.

This one however I read as Drake saying/asking that we should start
doing it now, and I tried to explain why we could not up until now, and
still cannot.   Correct me if I interpreted it wrongly.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Brian Jackson]

Martin Schlemmer wrote:
<snip>
>>
>>Big picture here:
>>* BDEPEND does nothing now, so don't worry about it if you don't want to
>>* in the future it will make other things possible
>>* give the man problems you see with the proposal, not just tell him that 
>>portage doesn't handle it right now... I think out of anyone, he knows what 
>>portage does and doesn't handle
>>
> 
> 
> I did ask Brian in another reply how he thought to implement it.
> 
> This one however I read as Drake saying/asking that we should start
> doing it now, and I tried to explain why we could not up until now, and
> still cannot.   Correct me if I interpreted it wrongly.
> 
> 

I don't know why we can't start now if we want. BDEPEND will be silently
ignored, so current versions of portage will just be blissfully ignorant.

Am I missing something?

Some of us think we can't start now, others think we can. I was under the
impression from ferringb that we could.

--Iggy
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On Tue, 2005-07-05 at 20:59 -0500, Brian Jackson wrote:
> Martin Schlemmer wrote:
> <snip>
> >>
> >>Big picture here:
> >>* BDEPEND does nothing now, so don't worry about it if you don't want to
> >>* in the future it will make other things possible
> >>* give the man problems you see with the proposal, not just tell him that 
> >>portage doesn't handle it right now... I think out of anyone, he knows what 
> >>portage does and doesn't handle
> >>
> > 
> > 
> > I did ask Brian in another reply how he thought to implement it.
> > 
> > This one however I read as Drake saying/asking that we should start
> > doing it now, and I tried to explain why we could not up until now, and
> > still cannot.   Correct me if I interpreted it wrongly.
> > 
> > 
> 
> I don't know why we can't start now if we want. BDEPEND will be silently
> ignored, so current versions of portage will just be blissfully ignorant.
> 
> Am I missing something?
> 

Yeah, I thought Drake was talking about DEPEND (that was at least what
he said), not BDEPEND.

> Some of us think we can't start now, others think we can. I was under the
> impression from ferringb that we could.
> 

BDEPEND should be fine to start now depending on faith.


-- 
Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]

Clarification, mixture of the emails I haven't responded to addressed 
here (further, sorry for the delay, didn't think the thread would go 
any further while I was offline for birthdays/4th of july stuff)...

On Wed, Jul 06, 2005 at 04:39:14AM +0200, Martin Schlemmer wrote:
> On Tue, 2005-07-05 at 20:59 -0500, Brian Jackson wrote:
> > Martin Schlemmer wrote:
> > <snip>
> > >>
> > >>Big picture here:
> > >>* BDEPEND does nothing now, so don't worry about it if you don't want to
> > >>* in the future it will make other things possible
> > >>* give the man problems you see with the proposal, not just tell him that 
> > >>portage doesn't handle it right now... I think out of anyone, he knows what 
> > >>portage does and doesn't handle
> > >>
> > > 
> > > 
> > > I did ask Brian in another reply how he thought to implement it.
> > > 
> > > This one however I read as Drake saying/asking that we should start
> > > doing it now, and I tried to explain why we could not up until now, and
> > > still cannot.   Correct me if I interpreted it wrongly.
> > > 
> > > 
> > 
> > I don't know why we can't start now if we want. BDEPEND will be silently
> > ignored, so current versions of portage will just be blissfully ignorant.
> > 
> > Am I missing something?
> > 
> 
> Yeah, I thought Drake was talking about DEPEND (that was at least what
> he said), not BDEPEND.
Adding it into DEPEND now would cause holy hell, definitely not 
advocating that approach, it's not backwards compatible and it's 
jumping the gun with no gain aside from breaking the tree since the 
current resolver likes to go loco.

Restating, the actual chost atoms *must* be seperated from ctarget 
deps.  It allows current portage to pretty much ignore them (thus not 
taxing the current resolver), and it provides portage with 
classification of those deps.

> 
> > Some of us think we can't start now, others think we can. I was under the
> > impression from ferringb that we could.
> > 
> 
> BDEPEND should be fine to start now depending on faith.
Not after having it rolled into the tree, _yet_.  First email pretty 
much stated I was just after seeing if it was tenuable beyond just the 
portage crews views on it :)

Basically, I was attempting to get feedback on issues where this 
wouldn't be quiet enough, an example of which is ncurses.
(my understanding of this, thanks to flameeyes for clueing me in)
ncurses built/installed in chost==ctarget, BDEPEND=
ncurses built/installed in chost!=ctarget, BDEPEND=ncurses

So... need to expose either ctarget as some type of flag for bdepend, 
or use flag type hack (native when chost=ctarget, -native when 
evaluating a use conditional in a domain where chost!=ctarget).

Thoughts regarding it?  I'd expect we'll have to expose ctarget info 
in some way for use conditionals, but would like some feedback on what 
else may be required.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[John Myers]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

On Tuesday 05 July 2005 02:39, Martin Schlemmer wrote:
> Also as already asked, what about the chicken egg issue ... (think tar
> needing tar, or gzip needing gzip to unpack)?

The stages could come primed with the data that the packages on them are 
already installed. 

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

On Wed, 2005-07-06 at 12:08 -0500, Brian D. Harring wrote:

> > 
> > > Some of us think we can't start now, others think we can. I was under the
> > > impression from ferringb that we could.
> > > 
> > 
> > BDEPEND should be fine to start now depending on faith.
> Not after having it rolled into the tree, _yet_.  First email pretty 
> much stated I was just after seeing if it was tenuable beyond just the 
> portage crews views on it :)
> 
> Basically, I was attempting to get feedback on issues where this 
> wouldn't be quiet enough, an example of which is ncurses.
> (my understanding of this, thanks to flameeyes for clueing me in)
> ncurses built/installed in chost==ctarget, BDEPEND=
> ncurses built/installed in chost!=ctarget, BDEPEND=ncurses
> 

Well, I can see that it can help towards that end.

> So... need to expose either ctarget as some type of flag for bdepend, 
> or use flag type hack (native when chost=ctarget, -native when 
> evaluating a use conditional in a domain where chost!=ctarget).
> 
> Thoughts regarding it?  I'd expect we'll have to expose ctarget info 
> in some way for use conditionals, but would like some feedback on what 
> else may be required.

Well, currently you have to export CTARGET for crossdev, etc, so either
keep that method, or add something to cvs portage to support
cross-compiling ?


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Kito]

On Jul 7, 2005, at 6:56 AM, John Myers wrote:

> On Tuesday 05 July 2005 02:39, Martin Schlemmer wrote:
>
>> Also as already asked, what about the chicken egg issue ... (think  
>> tar
>> needing tar, or gzip needing gzip to unpack)?
>>
>
> The stages could come primed with the data that the packages on  
> them are
> already installed.

This is what I've been doing with the experimental Darwin stages as  
nearly every basesystem package has circular deps...


Kito
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]

On Thursday 07 July 2005 21:44, Kito wrote:
> This is what I've been doing with the experimental Darwin stages as  
> nearly every basesystem package has circular deps...
Same with G/FBSD.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Jason Stubbs]

On Tuesday 05 July 2005 18:39, Martin Schlemmer wrote:
> On another note .. how do you guys plan to handle this BDEPEND .. just
> for x-compile, or global?  If global, any ideas how to solve the
> circular issues ???

Global. There's no real difference between building a package for the local 
machine or for another machine as far as deps go. If not global, there are 
circular issues involved anyway. Most of them are easy to overcome - just not 
easy to hack into the current implementation. If you've got concerns about a 
specific case, outline them please.

Regards,
jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Jason Stubbs]

On Thursday 07 July 2005 02:08, Brian D. Harring wrote:
> Basically, I was attempting to get feedback on issues where this
> wouldn't be quiet enough, an example of which is ncurses.
> (my understanding of this, thanks to flameeyes for clueing me in)
> ncurses built/installed in chost==ctarget, BDEPEND=
> ncurses built/installed in chost!=ctarget, BDEPEND=ncurses

I didn't read this in the thread. How does this work?

Regards,
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Jason Stubbs]

On Tuesday 05 July 2005 19:48, Martin Schlemmer wrote:
> This is all well and dandy, but try to add coreutils as a dependency of
> itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
> a stage1 install (probably stage2/3 as well, but I never do those, so
> rather wont comment).
>
> The point that Mike and I make, is that portage cannot handle this (and
> probably wont be able to in future without a _lot_ of black magic), and
> this is why we need the system profile which have just the right amount
> of DEPEND magic to make it work, and then everything else depends
> automagically on the system profile (and everything in it).  Making the
> adding of system packages to non system packages really redundant.

Portage can handle this because it doesn't look at BDEPEND. Black magic is not 
required. Black magic is what we have now that is causing so many problems.

Regards,
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Jason Stubbs]

On Monday 04 July 2005 09:18, Brian D. Harring wrote:
> On Fri, Jul 01, 2005 at 08:16:46PM -0500, Kito wrote:
> > Accurate deps should be a goal for the tree, a long term one
> > obviously...
>
> Picking at the words (not you), but "long term" == it gets ignored
> till someone starts screaming/foaming at the mouth.
>
> If BDEPEND were added, it's extra data that next version of
> portage could use to do crazy stuff, and it wouldn't screw up existing
> portage in anyway.
>
> What crazy stuff?  Aside from having _full_ deps so we can trust
> portage not to do something stupid if the profile is missing, BDEPEND
> provides classification of a set of atoms that must be native to a
> system.
>
> Since there is a seperation of what is effectively chost (bdepend) and
> ctarget (depend), you're giving portage a classification of depends
> for a package that it can use to do (what I'm calling) interdomain
> deps.

Aside from the "crazy stuff", the extra depend information will help get out 
of circular dependencies. To illustrate, I'll give an example.

foo DEPENDs on bar DEPENDs on baz RDEPENDs on foo
foo RDEPENDs on bar RDEPENDs on baz RDEPENDs on foo
Only foo is installed.

With the current available dependency information, this circular dependency 
cannot be broken. Why? It is not known whether a package's DEPENDs need to be 
executed or not. To be clear,

baz DEPENDs on foo
foo RDEPENDs on bar
bar is not installed.
foo might need to run bar for baz to build (implicit DEPEND from baz to bar)

If we add BDEPEND into the mix and "baz" doesn't have a BDEPEND on "foo" the 
circular dependency can be broken and the whole lot can be installed. Yes, it 
may be an extreme example but I can guarantee cases exist within the tree 
where circular deps can't be broken without BDEPEND information when a 
satisfying packages are not installed.

Furthermore, it will greatly speed up dependency resolution because there will 
actually be *fewer* dependencies to deal with.

Regards,
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Jason Stubbs]

On Saturday 02 July 2005 02:49, 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 ?

I'd agree with this as far as the compiling only. For the rest, they should 
really be RDEPENDs from portage (or whatever it is that provides econf, emake 
and unpack) itself. econf, emake and unpack are parts of the "ebuild 
environment" that every ebuild is guaranteed to have available.

However, if an ebuild chooses to run make directly for some unknown reason or 
use some specific tool to unpack an unsupported file format, the package 
should really be explicit about its dependency.

Regards,
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

On Saturday 09 July 2005 11:28, Jason Stubbs wrote:
> I didn't read this in the thread. How does this work?
ncurses needs to run a given binary (that I don't remember now, sorry), during 
the compilation stage. The build system try to build it bug if $CC != 
$BUILD_CC (literally) it considers it cross-compiling and doesn't try to run 
it (thinking that's a binary for another platform).
In this case it *needs* the same binary already installed in the system.

That means that when you're crosscompiling ncurses it requires a local copy of 
ncurses installed. To install the local copy, it doesn't need another local 
copy.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Saturday 09 July 2005 11:28, Jason Stubbs wrote:
> However, if an ebuild chooses to run make directly for some unknown reason
> or use some specific tool to unpack an unsupported file format, the package
> should really be explicit about its dependency.
And this let me think: we'll be able sooner or later to specify 'gmake' 
instead of make to avoid having aliases magic on G/FBSD systems? :)

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

On Sat, 2005-07-09 at 18:28 +0900, Jason Stubbs wrote:
> On Tuesday 05 July 2005 19:48, Martin Schlemmer wrote:
> > This is all well and dandy, but try to add coreutils as a dependency of
> > itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
> > a stage1 install (probably stage2/3 as well, but I never do those, so
> > rather wont comment).
> >
> > The point that Mike and I make, is that portage cannot handle this (and
> > probably wont be able to in future without a _lot_ of black magic), and
> > this is why we need the system profile which have just the right amount
> > of DEPEND magic to make it work, and then everything else depends
> > automagically on the system profile (and everything in it).  Making the
> > adding of system packages to non system packages really redundant.
> 
> Portage can handle this because it doesn't look at BDEPEND. Black magic is not 
> required. Black magic is what we have now that is causing so many problems.
> 

Ok, sorry, so maybe I went a bit overboard :)  The point I tried to make
is that with the current depend resolver this will not work, and we
cannot just start to add packages in the system profile to DEPEND all
over the place.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On Sat, 2005-07-09 at 11:47 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 11:28, Jason Stubbs wrote:
> > However, if an ebuild chooses to run make directly for some unknown reason
> > or use some specific tool to unpack an unsupported file format, the package
> > should really be explicit about its dependency.
> And this let me think: we'll be able sooner or later to specify 'gmake' 
> instead of make to avoid having aliases magic on G/FBSD systems? :)

I still this this is a bsd issue, so some or other solution which do not
include having gmake (and then later lots of other symlinks/whatever)
should be installed system wide for only a very small portion of our
user segment on all systems.  If its portage side only, fine.

If I am missing something, my apologies - I am just making my stance
clear.


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

On Saturday 09 July 2005 12:20, Martin Schlemmer wrote:
> I still this this is a bsd issue, so some or other solution which do not
> include having gmake (and then later lots of other symlinks/whatever)
> should be installed system wide for only a very small portion of our
> user segment on all systems.  If its portage side only, fine.
Trying to clear this:

gmake is installed in Linux systems with make and gmake names. This is true 
not only for Gentoo but also for most of the linux distributions I know.
A lot of scripts checks gmake support before 'make' and uses that if they 
found it.
Most of the autotools stuff works fine on both gmake and bsdish make.

There are a few cases in which we *really really really* need to use gmake 
(and a few we *really really really* need to use bsdmake).

What I'd like to see if 'make' used when every kind of make is supported (gnu, 
bsd, whatever will come) and 'gmake' or 'bsdmake' when they are strictly 
required.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

On Sat, 2005-07-09 at 13:45 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 12:20, Martin Schlemmer wrote:
> > I still this this is a bsd issue, so some or other solution which do not
> > include having gmake (and then later lots of other symlinks/whatever)
> > should be installed system wide for only a very small portion of our
> > user segment on all systems.  If its portage side only, fine.
> Trying to clear this:
> 
> gmake is installed in Linux systems with make and gmake names. This is true 
> not only for Gentoo but also for most of the linux distributions I know.
> A lot of scripts checks gmake support before 'make' and uses that if they 
> found it.
> Most of the autotools stuff works fine on both gmake and bsdish make.
> 
> There are a few cases in which we *really really really* need to use gmake 
> (and a few we *really really really* need to use bsdmake).
> 
> What I'd like to see if 'make' used when every kind of make is supported (gnu, 
> bsd, whatever will come) and 'gmake' or 'bsdmake' when they are strictly 
> required.

And this is exactly what one of the issue for me is.  Now devs on the
linux sides, need to learn bsd make peculiarities as well (to start
with, but it will expand if this gets in as 'policy' or whatever), and
hope to guess right when to use make/gmake.  BSD problem, BSD fixes it
them self (ie some sane way that do not require global ebuild scouring,
or BSD devs sweep the tree themselfs).

All though I still would have preferred some way without more ifdefs to
many ebuilds.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Saturday 09 July 2005 14:01, Martin Schlemmer wrote:
> And this is exactly what one of the issue for me is.  Now devs on the
> linux sides, need to learn bsd make peculiarities as well (to start
> with, but it will expand if this gets in as 'policy' or whatever), and
> hope to guess right when to use make/gmake.  BSD problem, BSD fixes it
> them self (ie some sane way that do not require global ebuild scouring,
> or BSD devs sweep the tree themselfs).
The solution is: use gmake, which is GNU for sure, in case we need to use 
bsdmake, we'll take care of it.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Stephen Bennett]

On Sat, 9 Jul 2005 14:08:24 +0200
"Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:

> On Saturday 09 July 2005 14:01, Martin Schlemmer wrote:
> > And this is exactly what one of the issue for me is.  Now devs on
> > the linux sides, need to learn bsd make peculiarities as well (to
> > start with, but it will expand if this gets in as 'policy' or
> > whatever), and hope to guess right when to use make/gmake.  BSD
> > problem, BSD fixes it them self (ie some sane way that do not
> > require global ebuild scouring, or BSD devs sweep the tree
> > themselfs).
> The solution is: use gmake, which is GNU for sure, in case we need to
> use bsdmake, we'll take care of it.

Alternatively, and less work for the ebuild devs, if most stuff works
with either then use `make` by default (as has always been done), and
if things don't work with the system's make we can change it around
when we come to keyword things.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

On Sat, 2005-07-09 at 14:08 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 14:01, Martin Schlemmer wrote:
> > And this is exactly what one of the issue for me is.  Now devs on the
> > linux sides, need to learn bsd make peculiarities as well (to start
> > with, but it will expand if this gets in as 'policy' or whatever), and
> > hope to guess right when to use make/gmake.  BSD problem, BSD fixes it
> > them self (ie some sane way that do not require global ebuild scouring,
> > or BSD devs sweep the tree themselfs).
> The solution is: use gmake, which is GNU for sure, in case we need to use 
> bsdmake, we'll take care of it.

Sure thing - YOU then go through the tree and change all instances of
'make' ...


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Saturday 09 July 2005 14:41, Martin Schlemmer wrote:
> Sure thing - YOU then go through the tree and change all instances of
> 'make' ...
Seems like the point is not taken.. I'm not saying to replace all of them 
*now* but just when we'll keyword stuff.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

On Sat, 2005-07-09 at 14:46 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 14:41, Martin Schlemmer wrote:
> > Sure thing - YOU then go through the tree and change all instances of
> > 'make' ...
> Seems like the point is not taken.. I'm not saying to replace all of them 
> *now* but just when we'll keyword stuff.
Ditto - point being, is that if you want the agony of per-ebuild hacks,
be my guest, but do not expect the rest to hold your hand.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On Saturday 09 July 2005 15:05, Martin Schlemmer wrote:
> Ditto - point being, is that if you want the agony of per-ebuild hacks,
> be my guest, but do not expect the rest to hold your hand.
It's not a matter of per-ebuild hack.
Let me explain for example:

for a bit of time we had make -> gmake alias on g/fbsd profiles, but emake 
still called plain "make" (bsdmake).
That was fine for most of the cases, gawk was the first one failing because it 
uess $(RM) which on gmake is an internal but it's not in other makes. The 
"good" solution was to fix the configure.in (or .ac i don't remember) to make 
sure that RM variable was set. That was discarded and we needed to let emake 
call gmake.

The problem of make/gmake is minimal, just a few corner cases, but I don't 
really like have to use alias make='gmake' in profiles.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 15:05, Martin Schlemmer wrote:
> > Ditto - point being, is that if you want the agony of per-ebuild hacks,
> > be my guest, but do not expect the rest to hold your hand.
> It's not a matter of per-ebuild hack.
> Let me explain for example:
> 
> for a bit of time we had make -> gmake alias on g/fbsd profiles, but emake 
> still called plain "make" (bsdmake).
> That was fine for most of the cases, gawk was the first one failing because it 
> uess $(RM) which on gmake is an internal but it's not in other makes. The 
> "good" solution was to fix the configure.in (or .ac i don't remember) to make 
> sure that RM variable was set. That was discarded and we needed to let emake 
> call gmake.
> 
> The problem of make/gmake is minimal, just a few corner cases, but I don't 
> really like have to use alias make='gmake' in profiles.

Could do a make wrapper similar to the emake one, that just
stips /usr/$(get_libdir)/portage/bin from PATH, and then run $MAKE.
Then bsd will only need to add MAKE=gmake to its profile, and change it
to MAKE=make or whatever for the bsd only stuff ?  (as I assume you
already have to do that for emake ...)

Anyhow, just a suggestion.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting build deps out from depends

[Kito]

I'll even top post this one :P Take it back to the thread flameeyes  
started about this originally pretty please, with sugar on top.

On Jul 9, 2005, at 9:10 AM, Martin Schlemmer wrote:

> On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote:
>
>> On Saturday 09 July 2005 15:05, Martin Schlemmer wrote:
>>
>>> Ditto - point being, is that if you want the agony of per-ebuild  
>>> hacks,
>>> be my guest, but do not expect the rest to hold your hand.
>>>
>> It's not a matter of per-ebuild hack.
>> Let me explain for example:
>>
>> for a bit of time we had make -> gmake alias on g/fbsd profiles,  
>> but emake
>> still called plain "make" (bsdmake).
>> That was fine for most of the cases, gawk was the first one  
>> failing because it
>> uess $(RM) which on gmake is an internal but it's not in other  
>> makes. The
>> "good" solution was to fix the configure.in (or .ac i don't  
>> remember) to make
>> sure that RM variable was set. That was discarded and we needed to  
>> let emake
>> call gmake.
>>
>> The problem of make/gmake is minimal, just a few corner cases, but  
>> I don't
>> really like have to use alias make='gmake' in profiles.
>>
>
> Could do a make wrapper similar to the emake one, that just
> stips /usr/$(get_libdir)/portage/bin from PATH, and then run $MAKE.
> Then bsd will only need to add MAKE=gmake to its profile, and  
> change it
> to MAKE=make or whatever for the bsd only stuff ?  (as I assume you
> already have to do that for emake ...)
>
> Anyhow, just a suggestion.
>
>
> -- 
> Martin Schlemmer
> Gentoo Linux Developer, Desktop/System Team Developer
> Cape Town, South Africa
>
>


-- 
gentoo-dev@gentoo.org mailing list