The devmanual reads unambiguously for me: All packages have an implicit compile-time and runtime dependency upon the entire system target. It is therefore not necessary, nor advisable, to specify dependencies upon toolchain packages like gcc, libc and so on, except where specific versions or packages (for example, glibc over uclibc) are required. (for packages in @system on every profile). Yet, kensington alerted me to this thread: http://archives.gentoo.org/gentoo-dev/msg_c715142451ccf83b7ea1505debccbe1f.xml where the verdict seems to be that things like zlib and xz-utils should be explicit (R)DEPENDs, as well as any @system library to which your package links. It would be nice if the devmanual could be updated to reflect this. The circumstances under which a package can be omitted from (R)DEPEND should be unambiguous, and the rationale for inclusion/exclusion would be a bonus.
(In reply to Michael Orlitzky from comment #0) > > where the verdict seems to be that things like zlib and xz-utils should be > explicit (R)DEPENDs, as well as any @system library to which your package > links. zlib -> gzip zlib isn't in @system, so it is clear that it should be depended upon explicitly.
(In reply to Michael Orlitzky from comment #0) > The devmanual reads unambiguously for me: > > All packages have an implicit compile-time and runtime dependency upon the > entire system target. It is therefore not necessary, nor advisable, to > specify > dependencies upon toolchain packages like gcc, libc and so on, except > where > specific versions or packages (for example, glibc over uclibc) are > required. You deleted the important part, it also says: "Note that this rule also needs consideration for packages like flex, zlib and libtool, which aren't in the system target for every profile. For example, the embedded profile doesn't have zlib in system target, the libtool ABI might change and break building order and flex might get removed from the system target in future." Which makes it clear it's case-by-case basis. This was added/changed exactly because of the reasons you listed here...
I understand why flex, libtool, and zlib must have explicit (R)DEPEND: if they aren't in @system for a particular profile, they may be unsatisfied. But what about gzip? It's in the base @system, yet if you link to it, you're still supposed to include it in RDEPEND according to the -dev thread. And flameeyes stated that being in @system is not the real issue. When should I include gzip in RDEPEND, then?
(In reply to Michael Orlitzky from comment #3) > I understand why flex, libtool, and zlib must have explicit (R)DEPEND: if > they aren't in @system for a particular profile, they may be unsatisfied. > > But what about gzip? It's in the base @system, yet if you link to it, you're > still supposed to include it in RDEPEND according to the -dev thread. And > flameeyes stated that being in @system is not the real issue. When should I > include gzip in RDEPEND, then? If the package uses it in any way (excluding the package manager unpacking the tarball), it should be included in (R)DEPEND. The system set contains the software packages that are required for a standard Gentoo Linux installation. It is not about providing dependencies for packages.
Perhaps the wording of "implicit compile-time and runtime dependency upon the entire system target" could be improved. With the exception of special packages like libc, gcc etc. other packages in @system are not that different from an automagic dependency if they are used.
(In reply to Michael Palimaka (kensington) from comment #4) > (In reply to Michael Orlitzky from comment #3) > > I understand why flex, libtool, and zlib must have explicit (R)DEPEND: if > > they aren't in @system for a particular profile, they may be unsatisfied. > > > > But what about gzip? It's in the base @system, yet if you link to it, you're > > still supposed to include it in RDEPEND according to the -dev thread. And > > flameeyes stated that being in @system is not the real issue. When should I > > include gzip in RDEPEND, then? > If the package uses it in any way (excluding the package manager unpacking > the tarball), it should be included in (R)DEPEND. Many packages use libc at runtime, but that gets a free pass. Is that the only one? (I'm not just arguing to be a pain in the ass, I really think it's unclear and will help people get their deps straight if we collect examples and rationale.)
(In reply to Michael Palimaka (kensington) from comment #5) > Perhaps the wording of "implicit compile-time and runtime dependency upon > the entire system target" could be improved. With the exception of special > packages like libc, gcc etc. other packages in @system are not that > different from an automagic dependency if they are used. The first two sentences, All packages have an implicit compile-time and runtime dependency upon the entire system target. It is therefore not ... advisable, to specify dependencies upon toolchain packages like gcc, libc and so on. say to me, "don't depend on things in @system." The toolchain packages (gcc, libc) are singled-out, but to me, it's saying that you *should* omit them *because* they're in @system. I'm happy to write the patch if there's some agreement on what it should contain.
I see nothing wrong with the current wording of the devmanual. Packages from the system set need not be included as dependencies because it can reasonably be assumed that they are present on every system. Exceptions exist for packages that are part of the system set themselves. Would we gain anything by requiring every package to include dependencies like glibc, bash, or coreutils? Or what is the rationale for this?
(In reply to Ulrich Müller from comment #8) > I see nothing wrong with the current wording of the devmanual. Packages from > the system set need not be included as dependencies because it can > reasonably be assumed that they are present on every system. Exceptions > exist for packages that are part of the system set themselves. > > Would we gain anything by requiring every package to include dependencies > like glibc, bash, or coreutils? Or what is the rationale for this? This is not about support packages like that (which may well be instead uclibc, zsh, or busybox), but rather dependencies that are explicitly needed by the package (such as linking against libz) that so happen to be in the system set.
Apart from virtual/libc, there are very few libraries in the system set (and zlib isn't among them, so of course it needs to be specified in *DEPEND). So what is this bug about then?
I believe this was originally about an ebuild switching from a bundled liblzma to xz-utils.
(In reply to Ulrich Müller from comment #10) > Apart from virtual/libc, there are very few libraries in the system set (and > zlib isn't among them, so of course it needs to be specified in *DEPEND). > > So what is this bug about then? Originally, xz-utils. I was under the impression that it did not need to be included as a dependency (since it's in @system). There is disagreement: 1. http://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml 2. http://archives.gentoo.org/gentoo-dev/msg_3acfceb893484e04cb8d4ec2cd79d39e.xml
(In reply to Michael Orlitzky from comment #12) > Originally, xz-utils. I was under the impression that it did not need to be > included as a dependency (since it's in @system). If your package links against liblzma, then I'd say that it should include xz-utils as an explicit dependency. This makes it easier to find such packages in case an alternative provider for liblzma should appear, or if the library should be split off into its own package at some future time. OTOH, if you just use xz for unpacking, then I think it's reasonable to assume that it exists on the system, i.e. it's the same as for other tools like gzip or bzip2 and no explicit dependency is needed. > There is disagreement: That was in 2011, and xz was much less popular then. By now, it has surpassed bzip2 and is on a par with gzip, at least when you count SRC_URI usage in the Portage tree.
(In reply to Ulrich Müller from comment #13) > (In reply to Michael Orlitzky from comment #12) > > Originally, xz-utils. I was under the impression that it did not need to be > > included as a dependency (since it's in @system). > > If your package links against liblzma, then I'd say that it should include > xz-utils as an explicit dependency. This makes it easier to find such > packages in case an alternative provider for liblzma should appear, or if > the library should be split off into its own package at some future time. So, we have an exception to the rule: if you link against something in @system, you should include it as an explicit dependency. And an exception to the exception to the rule: unless it's libc, or...?
(In reply to Ulrich Müller from comment #13) > OTOH, if you just use xz for unpacking, then I think it's reasonable to > assume that it exists on the system, i.e. it's the same as for other tools > like gzip or bzip2 and no explicit dependency is needed. I think we need more discussion about this. While it appears that it indeed was added to the system set for the purposes of unpacking tarballs, vapier and flameyes' posts seem to indicate that assuming it is not permitted. There are also a few bugs regarding this issue, including the relatively recent bug #456740. Also, PMS says that ebuilds must ensure that XZ utils are installed to unpack archives compressed with it (...but also says the same thing about all the other formats). Perhaps there is an improvement opportunity there too.
(In reply to Michael Palimaka (kensington) from comment #15) > > OTOH, if you just use xz for unpacking, then I think it's reasonable to > > assume that it exists on the system, i.e. it's the same as for other tools > > like gzip or bzip2 and no explicit dependency is needed. > I think we need more discussion about this. While it appears that it indeed > was added to the system set for the purposes of unpacking tarballs, vapier > and flameyes' posts seem to indicate that assuming it is not permitted. They made such statements, but without any reasoning. I don't see why we would treat xz differently from gzip, and what we would gain by adding xz-utils to DEPEND in several thousand ebuilds. > There are also a few bugs regarding this issue, including the relatively > recent bug #456740. That's about a package needed for stage building, which is special. > Also, PMS says that ebuilds must ensure that XZ utils are installed to > unpack archives compressed with it (...but also says the same thing about > all the other formats). Perhaps there is an improvement opportunity there > too. PMS also says: "Any ebuild not listed in the system set for the active profile(s) may assume the presence of every command that is always provided by the system set for that profile."
(In reply to Ulrich Müller from comment #16) In that case, it seems reasonable to not require xz-utils solely for the purpose of unpacking. It might be useful to make an announcement about that, given how many packages seem to implement such a dependency.
This seems like a good candidate to be put to the council, if for no other reason than because it will lovingly force someone to write up whatever detailed rules are decided upon. I'll send a message to -dev in a second for discussion.
No progress, therefore closing. Feel free to reopen with a patch attached.
