Test case: pkg_preinst() { einfo "${FUNCNAME}: $(best_version "${CATEGORY}/${PN}")"; } pkg_postinst() { einfo "${FUNCNAME}: $(best_version "${CATEGORY}/${PN}")"; } pkg_prerm() { einfo "${FUNCNAME}: $(best_version "${CATEGORY}/${PN}")"; } pkg_postrm() { einfo "${FUNCNAME}: $(best_version "${CATEGORY}/${PN}")"; } On upgrade: >>> Merging app-misc/testzor-2 to / * pkg_preinst: app-misc/testzor-1 >>> Safely unmerging already-installed instance... * pkg_prerm: app-misc/testzor-1 No package files given... Grabbing a set. * pkg_postrm: app-misc/testzor-1 >>> Original instance of package unmerged safely. * pkg_postinst: app-misc/testzor-2 >>> app-misc/testzor-2 merged. On removal: * pkg_prerm: app-misc/testzor-2 * pkg_postrm: app-misc/testzor-2 I'd say in post-remove, the package should be... removed :).
One could argue that the uninstall is not complete until the last phase function has returned.
(In reply to Ulrich Müller from comment #1) > One could argue that the uninstall is not complete until the last phase > function has returned. Yes, indeed. Also, REPLACING_VERSIONS makes it possible for ebuilds to distinguish between the relevant states, right? If so, then this quirk should not be a show-stopper for anyone.
(In reply to Ulrich Müller from comment #1) > One could argue that the uninstall is not complete until the last phase > function has returned. Same goes for install, yet pkg_postinst() assumes the package is already installed. (In reply to Zac Medico from comment #2) > (In reply to Ulrich Müller from comment #1) > > One could argue that the uninstall is not complete until the last phase > > function has returned. > > Yes, indeed. Also, REPLACING_VERSIONS makes it possible for ebuilds to > distinguish between the relevant states, right? If so, then this quirk > should not be a show-stopper for anyone. Well, yes, one has many ways of hacking arounds issues.
Remember what happened last time someone changed this behaviour...
(In reply to Ciaran McCreesh from comment #4) > Remember what happened last time someone changed this behaviour... Maybe you could 'remind' us? Because I'm not aware of it, and nobody seems to have bothered to document it in PMS.
(In reply to Michał Górny from comment #5) > (In reply to Ciaran McCreesh from comment #4) > > Remember what happened last time someone changed this behaviour... > > Maybe you could 'remind' us? Because I'm not aware of it, and nobody seems > to have bothered to document it in PMS. The behaviour was changed without EAPI control, breaking every package that used a version check to display a different message when upgrading. PMS got retroactively amended to match Portage's new behaviour. Someone spent ages fixing the tree. The Council promised that this would never be allowed to happen again.
(In reply to Ciaran McCreesh from comment #6) Do you refer to the change in call order (bug 174328, bug 338339)? What does Paludis output for the test case in comment #0? The same as Portage? Or maybe we should just say that the result of a self-referential call to has_version() or best_version(), while in a transitional install phase, is undefined.
I'll summarize the results with all 3 PMs in a minute.
I think it might be EAPI dependent in Paludis.
portage pkgcore paludis 1. install testzor-1 preinst (none) (none) (none) postinst testzor-1 testzor-1 testzor-1 2. upgrade to testzor-2 preinst testzor-1 testzor-1 testzor-1 prerm testzor-1 testzor-1 testzor-2 postrm testzor-1 testzor-1 testzor-2 postinst testzor-2 testzor-1 testzor-2 3. remove testzor-2 prerm testzor-2 testzor-2 testzor-2 postrm testzor-2 (none) testzor-2 Tested with EAPI 5.
Pretty sure it's dependent both upon the EAPI of the package being removed, and the EAPI of the package being installed in Paludis. We were pretty careful with this.
"Behaviour for a query matching the atom of the ebuild itself is undefined in pkg_preinst, pkg_postinst, pkg_prerm, and pkg_postrm." This would be added to the first paragraph of section 11.3.3.4 "Package manager query commands". http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-13200011.3.3.4
Sure. But provide a useful behavior for EAPI 6. There's no point in having a spec that doesn't allow you to solve stuff easily, especially when a easy solution is easy to implement.
It seems like making this consistent would requiring defining when the livefs (files/vdb/etc) must be written to for various operations (install/replace/remove). In my opinion, I think pkgcore clearly got it wrong for replacements so now it should provide the following output instead which I think is what most people would expect if the behavior for a query matching the atom of the ebuild itself was allowed to be undefined. pkgcore 1. install testzor-1 preinst (none) postinst testzor-1 2. upgrade to testzor-2 preinst testzor-1 prerm testzor-1 postrm testzor-2 postinst testzor-2 3. remove testzor-2 prerm testzor-2 postrm (none)
(In reply to Tim Harder from comment #14) > In my opinion, I think pkgcore clearly got it wrong for replacements so now > it should provide the following output instead which I think is what most > people would expect if the behavior for a query matching the atom of the > ebuild itself was allowed to be undefined. To correct myself, I meant if the behavior for a query matching the atom of the ebuild itself *wasn't* allowed to be undefined.
(In reply to Tim Harder from comment #14) > In my opinion, I think pkgcore clearly got it wrong for replacements so now > it should provide the following output instead which I think is what most > people would expect if the behavior for a query matching the atom of the > ebuild itself was allowed to be undefined. But that all depends upon the EAPI of the package being removed... The pkg_ phases aren't necessarily run in the order you expect.
(In reply to Ciaran McCreesh from comment #16) > (In reply to Tim Harder from comment #14) > > In my opinion, I think pkgcore clearly got it wrong for replacements so now > > it should provide the following output instead which I think is what most > > people would expect if the behavior for a query matching the atom of the > > ebuild itself was allowed to be undefined. > > But that all depends upon the EAPI of the package being removed... The pkg_ > phases aren't necessarily run in the order you expect. Can you point out where the pkg_ phase order changes in PMS due to EAPI? All I see is the note about EAPI 0 and 1 where the phase functions can (not must) be called in a different order which it also mentions is deprecated. Also thinking about it a bit more, probably paludis does it the expected way for replacements if we assume to write the new pkg changes to the livefs directly after pkg_preinst as PMS alludes to.
(In reply to Tim Harder from comment #17) > Can you point out where the pkg_ phase order changes in PMS due to EAPI? This is the thing from Comment #6 where Portage changed behaviours and PMS got retroactively changed. Paludis implements the old Portage behaviour for old EAPIs, and the new Portage behaviour for new EAPIs.
(In reply to Ciaran McCreesh from comment #18) > (In reply to Tim Harder from comment #17) > > Can you point out where the pkg_ phase order changes in PMS due to EAPI? > > This is the thing from Comment #6 where Portage changed behaviours and PMS > got retroactively changed. Paludis implements the old Portage behaviour for > old EAPIs, and the new Portage behaviour for new EAPIs. Ah thanks, that makes more sense now.
Is that really worth the effort? Since we have introduced REPLACING_VERSIONS and REPLACED_BY_VERSION variables, I'd consider best_version and has_version for the package itself as deprecated. Updated wording: "In the pkg_preinst, pkg_postinst, pkg_prerm, and pkg_postrm functions, behaviour is undefined for a query matching the atom of the ebuild itself, the atom replacing it, or the atom being replaced by it."
It's broken with Portage's parallel shenanigans too, so I'd say it's just plain undefined behaviour entirely, and should be banned in every phase.
(In reply to Ulrich Müller from comment #20) > Is that really worth the effort? Since we have introduced REPLACING_VERSIONS > and REPLACED_BY_VERSION variables, I'd consider best_version and has_version > for the package itself as deprecated. REPLAC* variables don't work for multi-slot packages.
(In reply to Ulrich Müller from comment #12) > "Behaviour for a query matching the atom of the ebuild itself is undefined > in pkg_preinst, pkg_postinst, pkg_prerm, and pkg_postrm." > > This would be added to the first paragraph of section 11.3.3.4 "Package > manager query commands". > http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-13200011.3.3.4 Hmm, please make that reference only the current slot. I don't see why you couldn't reference other slots.
(In reply to Michał Górny from comment #23) > Hmm, please make that reference only the current slot. I don't see why you > couldn't reference other slots. Portage might be changing other slots in parallel...
As well as doing anything to any other random packages. Your point?
The point is you can't expect them to work on other packages or slots either.
(In reply to Michał Górny from comment #23) > Hmm, please make that reference only the current slot. I don't see why you > couldn't reference other slots. I thought that the wording in comment #20 would account for it: "a query matching the atom of the ebuild itself, the atom replacing it, or the atom being replaced by it". This can match only the current slot. (In reply to Ciaran McCreesh from comment #24) > Portage might be changing other slots in parallel... Yes, or the package manager might be installing or removing the target of the query at some later point. So best_version is inherently unreliable and shouldn't be used for anything critical. But was this ever different?