Recently I created an ebuild new-atom, which installs the same files as original-atom but builds in a significantly different way. Since both install the same files, they cannot be installed on the system at the same time. Through a naive understanding of the difference between DEPEND and RDEPEND I decided that each package should simply DEPEND=!atom the other one. With original-atom installed, I attempted to install new-atom. Portage told me that it would unmerge original-atom then merge new-atom. new-atom went through the full proper installed, but original-atom was NOT unmerged first and when new-atom reached merge it collided files and died. After speaking to the fine fellows in #gentoo-dev-help I found that RDEPEND=!atom does cause the unmerging to happen in time so my issue is solved, but this is still an issue because I don't feel that expecting DEPENDS to be resolved pre-build is asking too much, nor is it a good thing that portage tells me it will uninstall something and then not follow through. As an added bonus, the RDEPEND=!atom version works, but it appears the unmerge happens after the merge which just seems wrong. I mean it didn't complain about anything, and it's all working, just looks scary is all.
ozzie compat-wireless-builder # ACCEPT_KEYWORDS=\~amd64 emerge compat-wireless-builder -vt1 These are the packages that would be merged, in reverse order: Calculating dependencies .... done! [nomerge ] net-wireless/compat-wireless-builder-3.4_rc3::pentoo USE="bluetooth injection -apply_cherrypicks -apply_crap -apply_pending -apply_stable -atheros_obey_crda -b43 -b44 -debug-driver -debugfs -full-debug -livecd -loadmodules -noleds -tarball" [blocks b ] net-wireless/compat-wireless ("net-wireless/compat-wireless" is blocking net-wireless/compat-wireless-builder-3.4_rc3) [uninstall ] net-wireless/compat-wireless-3.4_rc1-r1::pentoo USE="b43 b44 bluetooth injection -atheros_obey_crda -debug-driver -debugfs -full-debug -livecd -loadmodules -noleds" [ebuild N ] net-wireless/compat-wireless-builder-3.4_rc3::pentoo USE="bluetooth injection -apply_cherrypicks -apply_crap -apply_pending -apply_stable -atheros_obey_crda -b43 -b44 -debug-driver -debugfs -full-debug -livecd -loadmodules -noleds -tarball" 0 kB Total: 1 package (1 new, 1 uninstall), Size of downloads: 0 kB Conflict: 1 block >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-wireless/compat-wireless-builder-3.4_rc3 from pentoo ***snip really long compile*** >>> Source compiled. >>> Test phase [not enabled]: net-wireless/compat-wireless-builder-3.4_rc3 >>> Install compat-wireless-builder-3.4_rc3 into /var/tmp/portage/net-wireless/compat-wireless-builder-3.4_rc3/image/ category net-wireless >>> Completed installing compat-wireless-builder-3.4_rc3 into /var/tmp/portage/net-wireless/compat-wireless-builder-3.4_rc3/image/ ecompressdir: bzip2 -9 /usr/share/doc >>> Installing (1 of 1) net-wireless/compat-wireless-builder-3.4_rc3 * checking 125 files for package collisions * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). Once again, please do NOT file * a bug report unless you have completely understood the above message. * * Detected file collision(s): * * /lib64/udev/compat_firmware.sh * /lib64/udev/rules.d/50-compat_firmware.rules * /usr/lib/compat-wireless/modlib.sh * /usr/sbin/b43load * /usr/sbin/iwl-load * /usr/sbin/b43enable * /usr/sbin/madwifi-unload * /usr/sbin/unload.sh * /usr/sbin/iwl-enable * /usr/sbin/athload * /usr/sbin/athenable * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * net-wireless/compat-wireless-3.4_rc1-r1 * /lib64/udev/compat_firmware.sh * /lib64/udev/rules.d/50-compat_firmware.rules * /usr/lib/compat-wireless/modlib.sh * /usr/sbin/athenable * /usr/sbin/athload * /usr/sbin/b43enable * /usr/sbin/b43load * /usr/sbin/iwl-enable * /usr/sbin/iwl-load * /usr/sbin/madwifi-unload * /usr/sbin/unload.sh * * Package 'net-wireless/compat-wireless-builder-3.4_rc3' NOT merged due * to file collisions. If necessary, refer to your elog messages for the * whole content of the above message. >>> Failed to install net-wireless/compat-wireless-builder-3.4_rc3, Log file: >>> '/var/tmp/portage/net-wireless/compat-wireless-builder-3.4_rc3/temp/build.log' * Messages for package net-wireless/compat-wireless-builder-3.4_rc3: * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). Once again, please do NOT file * a bug report unless you have completely understood the above message. * * Detected file collision(s): * * /lib64/udev/compat_firmware.sh * /lib64/udev/rules.d/50-compat_firmware.rules * /usr/lib/compat-wireless/modlib.sh * /usr/sbin/b43load * /usr/sbin/iwl-load * /usr/sbin/b43enable * /usr/sbin/madwifi-unload * /usr/sbin/unload.sh * /usr/sbin/iwl-enable * /usr/sbin/athload * /usr/sbin/athenable * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * net-wireless/compat-wireless-3.4_rc1-r1 * /lib64/udev/compat_firmware.sh * /lib64/udev/rules.d/50-compat_firmware.rules * /usr/lib/compat-wireless/modlib.sh * /usr/sbin/athenable * /usr/sbin/athload * /usr/sbin/b43enable * /usr/sbin/b43load * /usr/sbin/iwl-enable * /usr/sbin/iwl-load * /usr/sbin/madwifi-unload * /usr/sbin/unload.sh * * Package 'net-wireless/compat-wireless-builder-3.4_rc3' NOT merged due * to file collisions. If necessary, refer to your elog messages for the * whole content of the above message. * * The following package has failed to build or install: * * (net-wireless/compat-wireless-builder-3.4_rc3::pentoo, ebuild scheduled for merge), Log file: * '/var/tmp/portage/net-wireless/compat-wireless-builder-3.4_rc3/temp/build.log' * * GNU info directory index is up-to-date.
DEPEND="!net-wireless/compat-wireless" RDEPEND=" livecd? ( =sys-kernel/linux-firmware-99999999 ) !livecd? ( >=sys-kernel/linux-firmware-20110709 ) sys-fs/udev" The above DEP and RDEP lines file with the above collisions DESPITE portage telling me it is going to uninstall the colliding package. The below DEP and RDEP lines yield the same emerge -vp output except function as expected and resolves the collision before merge. DEPEND="!net-wireless/compat-wireless" RDEPEND="${DEPEND} livecd? ( =sys-kernel/linux-firmware-99999999 ) !livecd? ( >=sys-kernel/linux-firmware-20110709 ) sys-fs/udev"
(In reply to comment #0) > After speaking to the fine fellows in #gentoo-dev-help I found that > RDEPEND=!atom does cause the unmerging to happen in time so my issue is > solved Why do you need it to be unmerged before? If it really needs to be unmerged before, then you need a hard !!atom blocker. If there are file collisions, then the blocker has to be in RDEPEND, because DEPEND is ignored for binary packages. > As an added bonus, the RDEPEND=!atom version works, but it appears the > unmerge happens after the merge which just seems wrong. I mean it didn't > complain about anything, and it's all working, just looks scary is all. As said, you need a hard !!atom blocker if you want it unmerged before.
(In reply to comment #3) > (In reply to comment #0) > > After speaking to the fine fellows in #gentoo-dev-help I found that > > RDEPEND=!atom does cause the unmerging to happen in time so my issue is > > solved > > Why do you need it to be unmerged before? If it really needs to be unmerged > before, then you need a hard !!atom blocker. If there are file collisions, > then the blocker has to be in RDEPEND, because DEPEND is ignored for binary > packages. binary packages? what binary package? this isn't a binary package.... and if you read the top portage CLEARLY states it is going to unmerge the colliding already installed package: [uninstall ] net-wireless/compat-wireless-3.4_rc1-r1::pentoo USE="b43 b44 bluetooth injection -atheros_obey_crda -debug-driver -debugfs -full-debug -livecd -loadmodules -noleds" Honestly how you choose to parse DEPEND is not something I have any right to lecture about, however, portage is lying to me, this is not acceptable. > > > As an added bonus, the RDEPEND=!atom version works, but it appears the > > unmerge happens after the merge which just seems wrong. I mean it didn't > > complain about anything, and it's all working, just looks scary is all. > > As said, you need a hard !!atom blocker if you want it unmerged before. RDEPEND=!atom causes it to be unmerged before, not sure why you want to force the user to interact with something which is so simple to just automatically fix but I'll just stick with the working solution instead of hard blocking for now. That said, imho, DEPEND=!atom should unmerge before build starts and RDEPEND=!atom should unmerge before merge. RDEPEND is working as expected, DEPEND is causing portage to lie to me then barf. I can't think of anything better classified as a bug.
(In reply to comment #4) > binary packages? what binary package? this isn't a binary package.... You could easily build a binary package with --buildpkg though, and file collisions will not be handled correctly for such a binary package unless the blocker is in RDEPEND. > and if > you read the top portage CLEARLY states it is going to unmerge the colliding > already installed package: > > [uninstall ] net-wireless/compat-wireless-3.4_rc1-r1::pentoo USE="b43 > b44 bluetooth injection -atheros_obey_crda -debug-driver -debugfs > -full-debug -livecd -loadmodules -noleds" > > Honestly how you choose to parse DEPEND is not something I have any right to > lecture about, however, portage is lying to me, this is not acceptable. It will unmerge the package, but first it has to install the replacement package, and that won't happen if there's a file collision. Maybe you're confused because the -t option causes the unmerge to show in reverse order? > RDEPEND=!atom causes it to be unmerged before, not sure why you want to > force the user to interact with something which is so simple to just > automatically fix but I'll just stick with the working solution instead of > hard blocking for now. Don't use a hard blocker unless it's necessary. It seems as though it's not necessary. However, it's the only way to force a package to be uninstalled beforehand. > That said, imho, DEPEND=!atom should unmerge before build starts and > RDEPEND=!atom should unmerge before merge. No, you need a hard !!atom blocker for that behavior. > RDEPEND is working as expected, > DEPEND is causing portage to lie to me then barf. I can't think of anything > better classified as a bug. It's working a designed. As explained, the blocker must be in RDEPEND in order for binary packages to work, since DEPEND is ignored for binary packages.
Okay so allow me to rephrase a bit. My original issue is solved by not being a moron and putting the blocker in RDEPEND where it belongs. That said, I feel that the DEPEND handling is wrong. This example may not be perfect for whatever reason, but please take the point I'm trying to make here not the specifics: DEPEND="virtual/linux-sources !hardened-sources" Currently, this will ensure that some version of linux-sources is installed, and continue building all the way through despite hardened-sources being installed and explicitly forbidden in the build DEPEND. After package merge hardened-sources would be removed, despite being used improperly to build. One of two things needs to happen to fix this: 1.) Make DEPEND actually work like RDEPEND already does, and the devmanual says they both should: http://devmanual.gentoo.org/ebuild-writing/eapi/#metadata This solution is most likely going to allow a little bit of excess stupidity to be allowed by users like myself who put things in DEPEND that really only belong in RDEPEND, but at the end of the day I don't see a huge amount of harm in this. 2.) Refuse to accept that there is any conceivable scenario where DEPEND=!atom is valid, in that case, portage/repoman should die when it encounters it and force either a hard block OR removal of the soft block. (Yes a warning would likely be best at first to give people time to fix their ebuilds before we break things in the tree which are working now; although a quick grep would show how bad it is) Personally I can't justify solution 1 to myself, however, solution 2 seems completely sane to me. Thoughts?
Upon rereading, solution 1 isn't sane in the first place and suffers the same issues are current implementation. DEPEND=!atom should be forbidden, only DEPEND=!!atom should be permitted. Quick and dirty solution could be to just make !atom==!!atom for DEPENDS processing. or a more full solution like my option 2 above. Sorry for the extra noise.
(In reply to comment #7) > Upon rereading, solution 1 isn't sane in the first place and suffers the > same issues are current implementation. > > DEPEND=!atom should be forbidden, only DEPEND=!!atom should be permitted. > > Quick and dirty solution could be to just make !atom==!!atom for DEPENDS > processing. or a more full solution like my option 2 above. Point taken, but that's not what PMS specification says to do. Portage is behaving according to the specification in this case. Install app-doc/pms if you'd like to read the spec.
(In reply to comment #6) > 2.) Refuse to accept that there is any conceivable scenario where > DEPEND=!atom is valid, in that case, portage/repoman should die when it > encounters it and force either a hard block OR removal of the soft block. > (Yes a warning would likely be best at first to give people time to fix > their ebuilds before we break things in the tree which are working now; > although a quick grep would show how bad it is) You could file a bug for pms-bugs@gentoo.org to have the PMS spec changed (either retroactively, or just in new EAPIs).
I'm closing this as resolved invalid because as of now I believe that is correct. I will read app-doc/pms and revisit this issue if I see something sane which can be done. If you want to make repoman yell at the user for doing DEPEND=!atom I wouldn't complain, but that is completely up to you to decide if that is a help or a burden. Thanks for your consideration.
(In reply to comment #10) > If you want to make repoman yell at the user for doing DEPEND=!atom I > wouldn't complain, but that is completely up to you to decide if that is a > help or a burden. It's common practice to do DEPEND="${RDEPEND}", so it would probably be mostly a burden since you'd have to fix lots of ebuilds to comply.
