http://devmanual.gentoo.org/general-concepts/dependencies/index.html The PDEPEND variable specifies dependencies which must be merged *after* the package. This is sometimes used for plugins which have a dependency upon the package being merged. Generally PDEPEND should be avoided in favour of RDEPEND except where this will create circular dependency chains. PMS: • Post dependencies (PDEPEND). These must be installed at some point before the package manager finishes the batch of installs. The most important difference is that PDEPEND may be installed before the actual package if there is no dependency cycle involved.
(and this page: http://devmanual.gentoo.org/ebuild-writing/variables/index.html)
I just teset PDEPEND with timezone-data and glibc: changed timezone-data-2014f to: DEPEND="sys-libs/glibc" and changed glibc-2.19-r1 to: PDEPEND+=" vanilla? ( !sys-libs/timezone-data ) !vanilla? ( sys-libs/timezone-data )" which gave me timzone-data before glibc anyway: ./cross-emerge -1a glibc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-libs/timezone-data-2014f to /usr/x86_64-tm-linux-gnu/ USE="-nls -right_timezone" [ebuild N ] sys-libs/glibc-2.19-r1 to /usr/x86_64-tm-linux-gnu/ USE="-debug -gd -hardened -multilib -nscd -profile (-selinux) -suid -systemtap -vanilla" Would you like to merge these packages? [Yes/No] n With and without --root-deps=rdeps
./cross-emerge --info Portage 2.2.12_p19_p172442 (python 2.7.7-final-0, embedded, gcc-4.7.3, unavailable, 3.12.21 x86_64) ================================================================= System uname: Linux-3.12.21-x86_64-Intel-R-_Core-TM-_i7-2600_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 12308032 total, 3243800 free KiB Swap: 4194300 total, 4194300 free Timestamp of tree: Thu, 11 Sep 2014 15:45:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 sys-kernel/linux-headers: 3.13 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA PUEL dlj-1.1 Oracle-BCLA-JavaSE AdobeFlash-11.x google-chrome" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-tm-linux-gnu" CONFIG_PROTECT="/etc /etc/entropy /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/portage/package.keywords/zzzautounmask /etc/portage/package.unmask/zzzautounmask /etc/portage/savedconfig /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/x86_64-tm-linux-gnu/usr/portage/distfiles" FCFLAGS="-Os -pipe" FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fakeroot fixlafiles merge-sync news nodoc noinfo noman parallel-fetch preserve-libs protect-owned sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersync" FFLAGS="-Os -pipe" GENTOO_MIRRORS="http://devsrv.transmode.se/portage http://devsrv.transmode.se/portage/local http://ftp.df.lth.se/pub/gentoo" LANG="en_GB.UTF-8" LDFLAGS="" MAKEOPTS="-j9 -l8 -s" PKGDIR="/usr/x86_64-tm-linux-gnu/packages/" PORTAGE_CONFIGROOT="/usr/x86_64-tm-linux-gnu/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/usr/x86_64-tm-linux-gnu/tmp/" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" USE="amd64 bindist kdrive minimal multicall prefix unicode zlib" ELIBC="glibc" INPUT_DEVICES="evdev mouse keyboard tslib" KERNEL="linux" LINGUAS="en" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" USERLAND="GNU" VIDEO_CARDS="fbdev" USE_PYTHON="2.7 3.3" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC
hmm, seems like the boths PMS specs are correct now but portage is not.
@mgorny: Is this supposed to be a bug against PMS or the devmanual?
(In reply to Ulrich Müller from comment #5) > @mgorny: Is this supposed to be a bug against PMS or the devmanual? Devmanual as 'Component' suggests :).
(In reply to Michał Górny from comment #6) > (In reply to Ulrich Müller from comment #5) > > @mgorny: Is this supposed to be a bug against PMS or the devmanual? > > Devmanual as 'Component' suggests :). Seems to me that the manual is correct now: "The PDEPEND variable specifies dependencies which must be merged after the package." The impl.(portage) is not though.
(In reply to Joakim Tjernlund from comment #7) > (In reply to Michał Górny from comment #6) > > (In reply to Ulrich Müller from comment #5) > > > @mgorny: Is this supposed to be a bug against PMS or the devmanual? > > > > Devmanual as 'Component' suggests :). > > Seems to me that the manual is correct now: > "The PDEPEND variable specifies dependencies which must be merged after the > package." No, that is the incorrect definition and the whole bug is about fixing it. Portage is correct.
(In reply to Michał Górny from comment #8) > (In reply to Joakim Tjernlund from comment #7) > > (In reply to Michał Górny from comment #6) > > > (In reply to Ulrich Müller from comment #5) > > > > @mgorny: Is this supposed to be a bug against PMS or the devmanual? > > > > > > Devmanual as 'Component' suggests :). > > > > Seems to me that the manual is correct now: > > "The PDEPEND variable specifies dependencies which must be merged after the > > package." > > No, that is the incorrect definition and the whole bug is about fixing it. > > Portage is correct. ehh, what is the point of PDEPEND then? If there is no particular order to PDEPEND I don't see the use. How whould you express my timezone-data / glibc exampel then?
(In reply to Joakim Tjernlund from comment #9) > (In reply to Michał Górny from comment #8) > > No, that is the incorrect definition and the whole bug is about fixing it. > > > > Portage is correct. > > ehh, what is the point of PDEPEND then? If there is no particular > order to PDEPEND I don't see the use. PDEPEND is intended to be used only when there is no other option. For example when two packages RDEPEND on each other, PDEPEND can be used to tell 'I need this package at runtime but you *may* merge it after me if there is no other option'. > How whould you express my timezone-data / glibc exampel then? If timezone-data requires glibc being installed first, then timezone-data should DEPEND on glibc. You can't inject that from glibc side.
(In reply to Michał Górny from comment #10) > (In reply to Joakim Tjernlund from comment #9) > > (In reply to Michał Górny from comment #8) > > > No, that is the incorrect definition and the whole bug is about fixing it. > > > > > > Portage is correct. > > > > ehh, what is the point of PDEPEND then? If there is no particular > > order to PDEPEND I don't see the use. > > PDEPEND is intended to be used only when there is no other option. For > example when two packages RDEPEND on each other, PDEPEND can be used to tell > 'I need this package at runtime but you *may* merge it after me if there is > no other option'. > > > How whould you express my timezone-data / glibc exampel then? > > If timezone-data requires glibc being installed first, then timezone-data > should DEPEND on glibc. You can't inject that from glibc side. Currently glibc does inject timezone-data and I trying to fix it. timezone-data does require glibc and I did add DEPEND on glibc. However, if I add a RDEPEND=glibc to timezone-data it works: timezone-data: DEPEND="!<sys-libs/glibc-2.3.5" RDEPEND="sys-libs/glibc" glibc: PDEPEND+=" vanilla? ( !sys-libs/timezone-data ) !vanilla? ( sys-libs/timezone-data )" ./cross-emerge -1a glibc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-libs/glibc-2.19-r1 to /usr/x86_64-tm-linux-gnu/ USE="-debug -gd -hardened -multilib -nscd -profile (-selinux) -suid -systemtap -vanilla" [ebuild N ] sys-libs/timezone-data-2014f to /usr/x86_64-tm-linux-gnu/ USE="-nls -right_timezone" I think this is correct as timezone-data has a few tools too which depends on glibc.
I agree the wording in the manual is wrong. I will commit whatever the PMS people give me to commit since they will be able to come up with the best possible patch.
Created attachment 389378 [details, diff] Patch for general-concepts/dependencies and ebuild-writing/variables (In reply to Markos Chandras from comment #12) > I agree the wording in the manual is wrong. I will commit whatever the PMS > people give me to commit since they will be able to come up with the best > possible patch. I believe that attached patch is in agreement with the PMS specification.
I like it. I will commit it. Thanks
Pushed. :)
