[gentoo-dev] Stage1 and dependencies

[gentoo-dev] Stage1 and dependencies

[Jason Stubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Two issues, but first the data:

# USE="-*" ./emerge.py -ep system
These are the packages that I would merge, in order:
Calculating dependencies done!

[ebuild   N   ] sys-devel/gnuconfig-20040214
[ebuild   N   ] sys-apps/cronbase-0.3
Using installed packages to build sys-devel/patch-2.5.9
[ebuild   N   ] sys-devel/patch-2.5.9
[ebuild   N   ] sys-kernel/linux-headers-2.4.22
[ebuild   N   ] app-arch/ncompress-4.2.4
[ebuild   N   ] sys-libs/db-4.1.25_p1-r4
Using installed packages to build app-arch/bzip2-1.0.2-r3
[ebuild   N   ] app-arch/bzip2-1.0.2-r3
Ignoring dependencies for sys-libs/glibc-2.3.3.20040420
[ebuild   N   ] sys-libs/glibc-2.3.3.20040420
[ebuild   N   ] sys-libs/ncurses-5.4-r2
[ebuild   N   ] sys-apps/sed-4.0.9
[ebuild   N   ] sys-apps/texinfo-4.6
[ebuild   N   ] sys-apps/groff-1.19
[ebuild   N   ] sys-apps/man-1.5m-r1
[ebuild   N   ] sys-libs/zlib-1.2.1-r2
[ebuild   N   ] dev-python/python-fchksum-1.7.1
[ebuild   N   ] dev-libs/expat-1.95.7
[ebuild   N   ] dev-lang/python-2.3.4
[ebuild   N   ] app-shells/bash-2.05b-r9
[ebuild   N   ] sys-apps/gawk-3.1.3-r1
[ebuild   N   ] sys-apps/modutils-2.4.26
[ebuild   N   ] app-shells/sash-3.7
[ebuild   N   ] app-editors/nano-1.3.2
[ebuild   N   ] net-misc/dhcpcd-1.3.22_p4-r5
[ebuild   N   ] dev-util/yacc-1.9.1-r2
[ebuild   N   ] sys-devel/flex-2.5.4a-r5
[ebuild   N   ] sys-apps/kbd-1.12-r2
[ebuild   N   ] app-arch/cpio-2.5
[ebuild   N   ] sys-fs/e2fsprogs-1.35
[ebuild   N   ] sys-apps/ed-0.2-r3
[ebuild   N   ] sys-apps/file-4.09
[ebuild   N   ] sys-apps/findutils-4.1.20-r1
[ebuild   N   ] sys-apps/miscfiles-1.3-r1
[ebuild   N   ] sys-apps/grep-2.5.1-r4
[ebuild   N   ] app-arch/gzip-1.3.3-r2
[ebuild   N   ] sys-apps/less-382-r2
[ebuild   N   ] sys-apps/man-pages-1.67
[ebuild   N   ] sys-apps/procps-3.2.1
[ebuild   N   ] sys-apps/psmisc-21.4
[ebuild   N   ] sys-apps/setserial-2.17-r2
[ebuild   N   ] app-arch/sharutils-4.2.1-r9
[ebuild   N   ] app-arch/tar-1.14
[ebuild   N   ] sys-apps/which-2.16
[ebuild   N   ] sys-devel/bin86-0.16.13
[ebuild   N   ] sys-devel/make-3.80
[ebuild   N   ] sys-libs/pwdb-0.62
[ebuild   N   ] sys-libs/readline-4.3-r5
[ebuild   N   ] sys-fs/devfsd-1.3.25-r8
Ignoring dependencies for sys-apps/portage-2.0.51_pre12
[ebuild   N   ] sys-apps/portage-2.0.51_pre12
[ebuild   N   ] sys-devel/libperl-5.8.4-r1
[ebuild   N   ] sys-devel/bc-1.06-r5
Ignoring dependencies for sys-devel/libtool-1.5.2-r5
[ebuild   N   ] sys-devel/libtool-1.5.2-r5
[ebuild   N   ] sys-devel/m4-1.4.1
[ebuild   N   ] dev-libs/popt-1.7-r1
[ebuild   N   ] dev-libs/glib-1.2.10-r5
Ignoring dependencies for sys-devel/gcc-3.3.3-r6
[ebuild   N   ] sys-devel/gcc-3.3.3-r6
[ebuild   N   ] dev-lang/perl-5.8.4
[ebuild   N   ] sys-devel/binutils-2.14.90.0.8-r1
[ebuild   N   ] sys-devel/autoconf-2.59-r4
[ebuild   N   ] sys-devel/automake-1.8.5-r1
[ebuild   N   ] sys-apps/help2man-1.33.1
[ebuild   N   ] sys-apps/coreutils-5.2.1
[ebuild   N   ] sys-apps/debianutils-1.16.7-r4
[ebuild   N   ] sys-devel/bison-1.875
[ebuild   N   ] sys-devel/gcc-config-1.3.6
[ebuild   N   ] sys-apps/util-linux-2.12-r4
[ebuild   N   ] sys-apps/baselayout-1.9.4-r2
[ebuild   N   ] dev-libs/openssl-0.9.7d-r1
[ebuild   N   ] net-misc/iputils-021109-r3
[ebuild   N   ] net-misc/rsync-2.6.1
[ebuild   N   ] net-misc/wget-1.9.1-r2
[ebuild   N   ] sys-apps/diffutils-2.8.7
[ebuild   N   ] sys-apps/fbset-2.1
[ebuild   N   ] sys-libs/cracklib-2.7-r9
[ebuild   N   ] sys-apps/shadow-4.0.4.1-r2
[ebuild   N   ] sys-apps/slocate-2.7-r5
[ebuild   N   ] sys-apps/hdparm-5.5
[ebuild   N   ] sys-apps/net-tools-1.60-r8
[ebuild   N   ] sys-libs/pam-0.77-r1
[ebuild   N   ] sys-apps/pam-login-3.14
[ebuild   N   ] net-misc/openssh-3.8.1_p1-r1


Issue #1: Ignoring dependencies

The "cleaning" of the vardb to trick portage is IMO a bad thing. There is 
obviously enough in a stage 1 to be able to build up all of system, but 
according to the data portage it is impossible. This then requires a hack as 
indicated above to attempt the merge anyway. However, this hack affects users 
of installed systems as well as portage will go ahead and attempt a 
compilation that is guaranteed to fail.

Plus there's the fact that files are left around unowned...

Issue #2: Lack of dependency information

Looking at the above, linux-headers doesn't need bzip2 to unpack, ncompress 
and db don't need glibc to build and almost nothing needs gcc to compile. It 
gets much worse when doing emerge -ep world. If it's too much of a PITA to 
fix this for all packages, portage could ensure that all of system is 
installed before anything else, but this needs to be 100% explicit for the 
base system. I don't believe it's as difficult as it sounds - a few eclasses 
such as bz2files, csource, cppsource, etc should be sufficient. However, 
without accurate information, parallel emerges are just a daydream.

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQN0SgFoikN4/5jfsAQKt1AQAnzecqLFJzo+kAK3W8wGE5Y1ACV/J+zWT
iw+Re6gx4GF1TujwSUDQiNi2hsRcwAypQnUvuJv+XqfdwMrVaCLbLc5SDFi1P95Q
hTrW+ZTCiiDWBfkUCYA08gnZbnASon2pso2pBkJUCH5p6yZP6JbMStqTxDCKr7zG
LSMkbKtc0Ws=
=Cuxp
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stage1 and dependencies

[Robin H. Johnson]

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

On Sat, Jun 26, 2004 at 03:06:52PM +0900, Jason Stubbs wrote:
> Issue #1: Ignoring dependencies
> The "cleaning" of the vardb to trick portage is IMO a bad thing. There is 
> obviously enough in a stage 1 to be able to build up all of system, but 
> according to the data portage it is impossible. This then requires a hack as 
> indicated above to attempt the merge anyway. However, this hack affects users 
> of installed systems as well as portage will go ahead and attempt a 
> compilation that is guaranteed to fail.
What's your solution for this?

> Issue #2: Lack of dependency information
> Looking at the above, linux-headers doesn't need bzip2 to unpack, ncompress 
> and db don't need glibc to build and almost nothing needs gcc to compile. It 
> gets much worse when doing emerge -ep world. If it's too much of a PITA to 
> fix this for all packages, portage could ensure that all of system is 
> installed before anything else, but this needs to be 100% explicit for the 
> base system. I don't believe it's as difficult as it sounds - a few eclasses 
> such as bz2files, csource, cppsource, etc should be sufficient. However, 
> without accurate information, parallel emerges are just a daydream.
I've got no objections to putting the correct information into the tree,
but portage needs to be able to handle circular dependancies much better
first. One other glaring problem in your listing is sys-devel/make. One
other thing that will bite at some points is the things that some
upstream developers put into their configure scripts, that are decidedly
not always present on a system (perl and rpm to name the worst offenders
I've seen). If you can tell me I won't run into any problems by adding
in the deps for virtual/libc virtual/cc sys-devel/make etc into my
packages, I'll go around and correct them now.

virtual/cc is something I think should exist, as some people want to use
dev-lang/icc or dev-lang/ccc instead of sys-devel/gcc.

Also, where does the adding of dependancies stop? Eg I have something
that uses kernel-headers and glibc, so do I just specify glibc and
ignore kernel-headers as that's needed by glibc?

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Stage1 and dependencies

[Jason Stubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 26 June 2004 17:06, Robin H. Johnson wrote:
> On Sat, Jun 26, 2004 at 03:06:52PM +0900, Jason Stubbs wrote:
> > Issue #1: Ignoring dependencies
> > The "cleaning" of the vardb to trick portage is IMO a bad thing. There is
> > obviously enough in a stage 1 to be able to build up all of system, but
> > according to the data portage it is impossible. This then requires a hack
> > as indicated above to attempt the merge anyway. However, this hack
> > affects users of installed systems as well as portage will go ahead and
> > attempt a compilation that is guaranteed to fail.
>
> What's your solution for this?

Well, I don't actually understand why the var db needs to be cleaned. I can't 
see why a combination of --nodeps and --onlydeps on package x and y can't 
solve whatever the problem is, though...

> > Issue #2: Lack of dependency information
> > Looking at the above, linux-headers doesn't need bzip2 to unpack,
> > ncompress and db don't need glibc to build and almost nothing needs gcc
> > to compile. It gets much worse when doing emerge -ep world. If it's too
> > much of a PITA to fix this for all packages, portage could ensure that
> > all of system is installed before anything else, but this needs to be
> > 100% explicit for the base system. I don't believe it's as difficult as
> > it sounds - a few eclasses such as bz2files, csource, cppsource, etc
> > should be sufficient. However, without accurate information, parallel
> > emerges are just a daydream.
>
> I've got no objections to putting the correct information into the tree,
> but portage needs to be able to handle circular dependancies much better
> first. One other glaring problem in your listing is sys-devel/make. One
> other thing that will bite at some points is the things that some
> upstream developers put into their configure scripts, that are decidedly
> not always present on a system (perl and rpm to name the worst offenders
> I've seen). If you can tell me I won't run into any problems by adding
> in the deps for virtual/libc virtual/cc sys-devel/make etc into my
> packages, I'll go around and correct them now.

I don't think that the change would bring about any more bad dependency 
ordering than already exists, but I can't be sure. Perhaps, the solution is 
to fix the dependency resolver then fix the packages and then enable parallel 
emerges. That sound acceptable?

> virtual/cc is something I think should exist, as some people want to use
> dev-lang/icc or dev-lang/ccc instead of sys-devel/gcc.
>
> Also, where does the adding of dependancies stop? Eg I have something
> that uses kernel-headers and glibc, so do I just specify glibc and
> ignore kernel-headers as that's needed by glibc?

That's a design question that's open to debate. Portage can do it either way, 
but I would suggest that the package depend on both kernel-headers and glibc 
for robustness in the tree. Unlikely in this case, but it ensures that a 
change to glibc's dependencies don't break the packages that depend on it.

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQN1Bh1oikN4/5jfsAQIn1AP+JpYCphzGsFLJlm6hnntLfGaJ+KWjjb61
UNR4sw7q/qRq4GfNliBfNetb16K6jjBRseZUrt9p5ofdjgu6nCxEyfl5F+0QyPSH
sAZq0eqFcobARU+TUPGGBeJG82ve46BJDCTPF4ieK3dFm4/0sfRYHz+DAYQnNFG6
eq507/u1bRM=
=3rkH
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stage1 and dependencies

[Robin H. Johnson]

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

On Sat, Jun 26, 2004 at 06:27:30PM +0900, Jason Stubbs wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Saturday 26 June 2004 17:06, Robin H. Johnson wrote:
> > On Sat, Jun 26, 2004 at 03:06:52PM +0900, Jason Stubbs wrote:
> > > Issue #1: Ignoring dependencies
> > > The "cleaning" of the vardb to trick portage is IMO a bad thing. There is
> > > obviously enough in a stage 1 to be able to build up all of system, but
> > > according to the data portage it is impossible. This then requires a hack
> > > as indicated above to attempt the merge anyway. However, this hack
> > > affects users of installed systems as well as portage will go ahead and
> > > attempt a compilation that is guaranteed to fail.
> > What's your solution for this?
> Well, I don't actually understand why the var db needs to be cleaned. I can't 
> see why a combination of --nodeps and --onlydeps on package x and y can't 
> solve whatever the problem is, though...
Try it and see :-), if you don't see why it shouldn't work, it should
probably work... if not fix it ;-).

> > I've got no objections to putting the correct information into the tree,
> > but portage needs to be able to handle circular dependancies much better
> > first. One other glaring problem in your listing is sys-devel/make. One
> > other thing that will bite at some points is the things that some
> > upstream developers put into their configure scripts, that are decidedly
> > not always present on a system (perl and rpm to name the worst offenders
> > I've seen). If you can tell me I won't run into any problems by adding
> > in the deps for virtual/libc virtual/cc sys-devel/make etc into my
> > packages, I'll go around and correct them now.
> I don't think that the change would bring about any more bad dependency 
> ordering than already exists, but I can't be sure. Perhaps, the solution is 
> to fix the dependency resolver then fix the packages and then enable parallel 
> emerges. That sound acceptable?
Yup, that should be fine. Before .51 comes out, could you maybe add a
bit of code in repoman to detect circular dependancies (and give a
non-fatal warning at the moment), so we can work on them from an early
stage?

I see two cases of circular dependancies that need to be worried about:
- Directly: 
  pkgA DEPEND on pkgB, and pkgB DEPEND on pkgA - The only solution here
  is to code something to work around the circular dependancy, via
  bootstrapping one of the packages (similar to getting gcc onto a
  machine without a compiler). I know at least one case of this existing
  in the tree at a point, but I think it's been fixed at the moment.
  
- Conditionally directly: 
  openldap:DEPEND="sasl? ( cyrus-sasl )"
  cyrus-sasl:DEPEND="ldap? ( openldap )"
  This one is much simpler, just build one of the two without the USE
  flag that causes the circular trap. Then build the other package, and
  rebuild the first. Hard part would be choosing which one to build
  without the USE flag. A few bugs like this exact one exist, see bug
  #33440 to track them.

> > virtual/cc is something I think should exist, as some people want to use
> > dev-lang/icc or dev-lang/ccc instead of sys-devel/gcc.
> >
> > Also, where does the adding of dependancies stop? Eg I have something
> > that uses kernel-headers and glibc, so do I just specify glibc and
> > ignore kernel-headers as that's needed by glibc?
> That's a design question that's open to debate. Portage can do it either way, 
> but I would suggest that the package depend on both kernel-headers and glibc 
> for robustness in the tree. Unlikely in this case, but it ensures that a 
> change to glibc's dependencies don't break the packages that depend on it.
Ok, so listing as many dependancies as required (within reason) is
suitable. One other question comes up in your mention of eclasses to
make it easier, namely what's the speed hit going to be with so many
eclasses being added to packages? Won't it be better to change ebuilds
directly?

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Stage1 and dependencies

[Jason Stubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 26 June 2004 18:52, Robin H. Johnson wrote:
> On Sat, Jun 26, 2004 at 06:27:30PM +0900, Jason Stubbs wrote:
> > On Saturday 26 June 2004 17:06, Robin H. Johnson wrote:
> > > On Sat, Jun 26, 2004 at 03:06:52PM +0900, Jason Stubbs wrote:
> > > > Issue #1: Ignoring dependencies
> > > > The "cleaning" of the vardb to trick portage is IMO a bad thing.
> > > > There is obviously enough in a stage 1 to be able to build up all of
> > > > system, but according to the data portage it is impossible. This then
> > > > requires a hack as indicated above to attempt the merge anyway.
> > > > However, this hack affects users of installed systems as well as
> > > > portage will go ahead and attempt a compilation that is guaranteed to
> > > > fail.
> > >
> > > What's your solution for this?
> >
> > Well, I don't actually understand why the var db needs to be cleaned. I
> > can't see why a combination of --nodeps and --onlydeps on package x and y
> > can't solve whatever the problem is, though...
>
> Try it and see :-), if you don't see why it shouldn't work, it should
> probably work... if not fix it ;-).

(The following was in regards to this "fix it" - but I just realized that you 
were probably talking about bootstrap.sh :)

I've rewritten the dependency checker as part of the API, but it would be a 
_real_ pain to port it back to portage. The main issue with the current dep 
resolver is that if A reqs B and C, and B reqs C, the dep resolution is:
* check A
* add A to the resolved order, add A to the graph
* check B
* add B to the resolved order, add B to the graph
* add dep from A to B
* check C (as dep from B)
* add C to the resolved order, add C to the graph
* add dep from B to C
* check C (as dep from A)
* C exists in graph, skip it.

The dep from A to C is not included. Emerging goes:
* First package added is A.. has deps? yes
* Next package added is B.. has deps? yes
* Next package added is C.. has deps? no.
* Install C and remove its deps.
* First package added is A.. has deps? yes
* Next package added is B.. has deps? no.
* Install B and remove its deps.
* First package added is A.. has deps? no.
* Install A and remove its deps.

Hence, the order is usually right but can go wrong when circular dependencies 
come into play.

> > > I've got no objections to putting the correct information into the
> > > tree, but portage needs to be able to handle circular dependancies much
> > > better first. One other glaring problem in your listing is
> > > sys-devel/make. One other thing that will bite at some points is the
> > > things that some upstream developers put into their configure scripts,
> > > that are decidedly not always present on a system (perl and rpm to name
> > > the worst offenders I've seen). If you can tell me I won't run into any
> > > problems by adding in the deps for virtual/libc virtual/cc
> > > sys-devel/make etc into my packages, I'll go around and correct them
> > > now.
> >
> > I don't think that the change would bring about any more bad dependency
> > ordering than already exists, but I can't be sure. Perhaps, the solution
> > is to fix the dependency resolver then fix the packages and then enable
> > parallel emerges. That sound acceptable?
>
> Yup, that should be fine. Before .51 comes out, could you maybe add a
> bit of code in repoman to detect circular dependancies (and give a
> non-fatal warning at the moment), so we can work on them from an early
> stage?

I think circular dependencies are inevitable. gcc requires glibc and glibc 
requires gcc. I don't think there's anything that can be done about that.

> I see two cases of circular dependancies that need to be worried about:
> - Directly:
>   pkgA DEPEND on pkgB, and pkgB DEPEND on pkgA - The only solution here
>   is to code something to work around the circular dependancy, via
>   bootstrapping one of the packages (similar to getting gcc onto a
>   machine without a compiler). I know at least one case of this existing
>   in the tree at a point, but I think it's been fixed at the moment.

Presently, I'm using the following logic:
1. Install all packages that have no dependencies and remove them from the
   graph.
2. Go back to 1, unless there are no leaf packages.
3. Find the smallest circular dependency set.
4. Find the total number of reverse dependencies for each package in the set.
   (A deps on B deps on C deps on D - D has 3 rather than 1)
5. Starting with the package with the most reverse deps, iterate through all 
   packages on each of the following steps:
   a. Install it and go back to 1 if installed packages can satisfy all of its
      dependencies.
6. Ignore dependencies for the package with the most reverse deps.

I want to add a 5c for cases where:
foo-1 is installed.
foo-3 is the latest and requires >=bar-3
bar-3 requires >=foo-2
foo-2 requires >= bar-2
bar-2 requires >= foo-1

> - Conditionally directly:
>   openldap:DEPEND="sasl? ( cyrus-sasl )"
>   cyrus-sasl:DEPEND="ldap? ( openldap )"
>   This one is much simpler, just build one of the two without the USE
>   flag that causes the circular trap. Then build the other package, and
>   rebuild the first. Hard part would be choosing which one to build
>   without the USE flag. A few bugs like this exact one exist, see bug
>   #33440 to track them.

I will be addding a 5b for this.

> > > virtual/cc is something I think should exist, as some people want to
> > > use dev-lang/icc or dev-lang/ccc instead of sys-devel/gcc.
> > >
> > > Also, where does the adding of dependancies stop? Eg I have something
> > > that uses kernel-headers and glibc, so do I just specify glibc and
> > > ignore kernel-headers as that's needed by glibc?
> >
> > That's a design question that's open to debate. Portage can do it either
> > way, but I would suggest that the package depend on both kernel-headers
> > and glibc for robustness in the tree. Unlikely in this case, but it
> > ensures that a change to glibc's dependencies don't break the packages
> > that depend on it.
>
> Ok, so listing as many dependancies as required (within reason) is
> suitable. One other question comes up in your mention of eclasses to
> make it easier, namely what's the speed hit going to be with so many
> eclasses being added to packages? Won't it be better to change ebuilds
> directly?

Well, caching should make it fine for end users in terms of eclasses. Brian 
Harring is currently looking at speeding up portage's bash usage in a way 
that should more than counter any speed loss, though. More on my mind is the 
memory and cpu requirements for the shear number of dependencies that there 
actually are... The dependency graph is much easier and quicker to process if 
it can be assumed that all packages explicitly state all dependencies, but 
the actual building of the graph would take more time.

Really, I can only offer an opinion on this question. The choice is should 
really be made by people who have been maintaining ebuilds for a long time. 
Which way would be easier to maintain?

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQN1mCFoikN4/5jfsAQLdKQP/fend4MJOZyn57jR/WqgG2wWJ39x/cMpV
hjc35ze6oNR2AnKx9L8kGDmDKPudOkVBX6YlOsaL7DFDDtQjXei/RJCfRpA2NiAi
TrtJlS4VVg9BAWgOvUw2m9L5bA/k6U9WaZgnrfKbp+yVPS3sbn332GaPVetM7INp
CQ9RtvarAtg=
=7Ysg
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stage1 and dependencies

[Chris Gianelloni]

On Sat, 2004-06-26 at 04:06, Robin H. Johnson wrote:
> Also, where does the adding of dependancies stop? Eg I have something
> that uses kernel-headers and glibc, so do I just specify glibc and
> ignore kernel-headers as that's needed by glibc?

I was under the impression that there is no need to list anything that
is in the "system" profile.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stage1 and dependencies

[Jason Stubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 26 June 2004 23:01, Chris Gianelloni wrote:
> On Sat, 2004-06-26 at 04:06, Robin H. Johnson wrote:
> > Also, where does the adding of dependancies stop? Eg I have something
> > that uses kernel-headers and glibc, so do I just specify glibc and
> > ignore kernel-headers as that's needed by glibc?
>
> I was under the impression that there is no need to list anything that
> is in the "system" profile.

As I said, it's reasonable that apps outside of system don't need to depend on 
anything within system but stuff in system needs to be explicit about what it 
needs. However, if that's the choice that is made I suggest that there be a 
document stating explicity what the bare minimum that is that system must 
provide.

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQN2Cv1oikN4/5jfsAQIdUQP+OKw3HL/OIYQXihdgbntDoUqkxa9uaaod
CqaCnAR1Ru7o7XzfxvkegAl4llnFKtVIbebNFhVwQOR2k2aGvjmRFTxbrLbDgk/z
vhARCxAJNZJGkew3mAe7lz4/69XA+0UAkWWaFd2U78UcZ/c7jZasW0K0yDJ6NsW3
NNC9qm/b6Jw=
=d4Uj
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stage1 and dependencies

[Chris Gianelloni]

On Sat, 2004-06-26 at 10:05, Jason Stubbs wrote:
> As I said, it's reasonable that apps outside of system don't need to depend on 
> anything within system but stuff in system needs to be explicit about what it 
> needs. However, if that's the choice that is made I suggest that there be a 
> document stating explicity what the bare minimum that is that system must 
> provide.

Ahh... I misunderstood.  Yes, everything in system should be very
explicit, as that resolves problems of dependencies changing.  Though I
do agree that it would be a good idea to have a defined set of "these
will always be provided by system" so we know what'll be available.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux


--
gentoo-dev@gentoo.org mailing list