Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Michael Orlitzky wrote: > You're missing some context. In October of last year, a QA team member > broke dependency resolution on a lot of systems by making the same sort > of change that this patch proposes: > https://archives.gentoo.org/gentoo-dev/message/64c42804eb4cf4bc7d1161a2e9222c6a Which is very different from what this patch suggests. For example, virtual/pam had been package masked at the time, while mgorny's patch explicitly says that a virtual should _not_ be masked prior to its removal. > Last month, someone brought up that example and named the QA team as > partly responsible for the --changed-deps requirement, which goes > against the PMS and a council decision: > https://archives.gentoo.org/gentoo-dev/message/dcebabbd6f13aed6622424d439f7becc Again, very different case which had nothing to do with removal of a virtual. > Shortly thereafter, another QA member opened a pull request that would > retroactively make what the first QA member did OK: > https://github.com/gentoo/devmanual/pull/177 See my first paragraph above. > And now, we are having a third QA team member in charge of approving > that change to the devmanual, which will later be cited as "policy." > Your problem is that you're not a member of the right gang. Ad-hominem attacks won't help us here. Ulrich
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On 2020-09-07 08:47, Alessandro Barbieri wrote: > Being consistent in decision is hard I see. You're missing some context. In October of last year, a QA team member broke dependency resolution on a lot of systems by making the same sort of change that this patch proposes: https://archives.gentoo.org/gentoo-dev/message/64c42804eb4cf4bc7d1161a2e9222c6a Last month, someone brought up that example and named the QA team as partly responsible for the --changed-deps requirement, which goes against the PMS and a council decision: https://archives.gentoo.org/gentoo-dev/message/dcebabbd6f13aed6622424d439f7becc Shortly thereafter, another QA member opened a pull request that would retroactively make what the first QA member did OK: https://github.com/gentoo/devmanual/pull/177 And now, we are having a third QA team member in charge of approving that change to the devmanual, which will later be cited as "policy." Your problem is that you're not a member of the right gang.
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Alessandro Barbieri wrote: > Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller ha > scritto: >> We are talking about the second case here, because the dependency on the >> virtual is being removed, while the dependency on its provider remains >> in place (it only changes from an indirect to a direct dependency). > That what's I've done here > https://github.com/gentoo/gentoo/pull/13443#issuecomment-553764133 but > you decided to make me do a revbump. > Being consistent in decision is hard I see. I still stand by what I said there: | Exceptions are packages that take a long time to build, where you may | want to use common sense and weigh the negative impact of not doing a | revbump against build time on users' systems (and in those cases, it | can sometimes be avoided, e.g., by delaying the change until the next | version bump). Also I don't see how this would be a contradiction. In your case it was a revbump of a single ebuild with negligible build time. Here, we're talking about removal of a virtual, which may require a rebuild of many packages on users' systems if everything was revbumped. Ulrich
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller ha scritto: > The devmanual [1] says that a revbump should be done when a new runtime > dependency is added to an ebuild, but it doesn't say that for removal of > a dependency. > > We are talking about the second case here, because the dependency on the > virtual is being removed, while the dependency on its provider remains > in place (it only changes from an indirect to a direct dependency). > > Ulrich > > [1] > https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html > > That what's I've done here https://github.com/gentoo/gentoo/pull/13443#issuecomment-553764133 but you decided to make me do a revbump. Being consistent in decision is hard I see.
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Michael Orlitzky wrote: > On 2020-09-07 08:10, Ulrich Mueller wrote: >> The devmanual [1] says that a revbump should be done when a new >> runtime dependency is added to an ebuild, but it doesn't say that for >> removal of a dependency. > One dependency is removed, and another is added. All completely > besides the point that this breaks things. Except that it doesn't, in this special case. Ulrich
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On 2020-09-07 08:10, Ulrich Mueller wrote: >> This has caused dependency resolution problems in the past. The PMS >> implies a new revision, > > PMS says nothing about new revisions or revision bumps: > That is indeed what the word "implies" implies. > The devmanual [1] says that a revbump should be done when a new runtime > dependency is added to an ebuild, but it doesn't say that for removal of > a dependency. > One dependency is removed, and another is added. All completely besides the point that this breaks things.
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Michael Orlitzky wrote: > On 2020-09-07 02:14, Michał Górny wrote: >> + >> +Update all ebuilds not to reference the virtual. Since there is >> +no urgent need to remove the virtual from user systems >> +and the resulting rebuilds would be unnecessary, do not bump ebuilds >> +when replacing the dependency. >> + > This has caused dependency resolution problems in the past. The PMS > implies a new revision, PMS says nothing about new revisions or revision bumps: $ grep -i "new revision" pms/*.tex $ grep -i bump pms/*.tex $ > the council said make a new revision, and the devmanual already says > make a new revision. [...] The devmanual [1] says that a revbump should be done when a new runtime dependency is added to an ebuild, but it doesn't say that for removal of a dependency. We are talking about the second case here, because the dependency on the virtual is being removed, while the dependency on its provider remains in place (it only changes from an indirect to a direct dependency). Ulrich [1] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On 2020-09-07 02:14, Michał Górny wrote: > + > +Update all ebuilds not to reference the virtual. Since there is > +no urgent need to remove the virtual from user systems > +and the resulting rebuilds would be unnecessary, do not bump ebuilds > +when replacing the dependency. > + This has caused dependency resolution problems in the past. The PMS implies a new revision, the council said make a new revision, and the devmanual already says make a new revision. Documenting this behavior might make people feel better about ignoring all of that, but your lack of guilt doesn't do me any good when portage starts crashing.
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 7 Sep 2020 21:39:54 +1200 Kent Fredric wrote: > On Mon, 7 Sep 2020 08:14:52 +0200 > Michał Górny wrote: > > > However, please > > +do not include it in the package.mask entry as users do > > not need > > +to be forced to proactively unmerge it. > > I can think of a utilitarian value of doing this anyway. > > Namely, it gives a window during `emerge -uD @world` where portage > tells you that they have a masked package installed, and the reason. I think portage also warns for installed packages with no corresponding ebuild; the reason is somewhat generic though (sth like 'it is gone') IMHO last rites windows have only one purpose: give time to people to step up and fix the reason why it is going away -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCX1YK/gAKCRAOJUi7xgfl rrooAQCBK/WXgwMl1wm8jQh+e2oyD8WIAzSrzFFBCE7xWL1WGgEAgWSGBmG9ug8/ ZNfrHnOhBL2o6hZupzMy/84dX7DFBvk= =pwzN -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On Mon, 7 Sep 2020 08:14:52 +0200 Michał Górny wrote: > However, please > +do not include it in the package.mask entry as users do not need > +to be forced to proactively unmerge it. I can think of a utilitarian value of doing this anyway. Namely, it gives a window during `emerge -uD @world` where portage tells you that they have a masked package installed, and the reason. Ideally, people don't have virtuals in their world file, but they do anyway, which means you can't guarantee the lack of dependents resulting in a depclean directed purge. And this can matter, as if its in your world file, or sometimes, if its even still installed, portage can trip up during upgrades with a more confusing error about the virtual not being installable. Outdated overlays add to this problem somewhat. :/ pgpsytvtxUHNq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
On Mon, 2020-09-07 at 09:46 +0200, Ulrich Mueller wrote: > > > > > > On Mon, 07 Sep 2020, Michał Górny wrote: > > + > > +If the virtual is being removed along with its second to last > > +provider, include the virtual in the last-rites mail. However, please > > Maybe write "any of its providers" instead of "its second to last > provider"? It is simpler and still has the same meaning. Done. > > > +do not include it in the package.mask entry as users do not need > > +to be forced to proactively unmerge it. Instead, add it > > +to package.deprecated to warn developers not to depend on it. > > +Wait the time appropriate for the last rites. > > + -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
> On Mon, 07 Sep 2020, Michał Górny wrote: > + > +If the virtual is being removed along with its second to last > +provider, include the virtual in the last-rites mail. However, please Maybe write "any of its providers" instead of "its second to last provider"? It is simpler and still has the same meaning. > +do not include it in the package.mask entry as users do not need > +to be forced to proactively unmerge it. Instead, add it > +to package.deprecated to warn developers not to depend on it. > +Wait the time appropriate for the last rites. > + signature.asc Description: PGP signature
[gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
Signed-off-by: Michał Górny --- ebuild-maintenance/removal/text.xml | 43 + 1 file changed, 43 insertions(+) diff --git a/ebuild-maintenance/removal/text.xml b/ebuild-maintenance/removal/text.xml index eabbdaf..3575b5c 100644 --- a/ebuild-maintenance/removal/text.xml +++ b/ebuild-maintenance/removal/text.xml @@ -83,6 +83,49 @@ Date: Tue Oct 3 21:43:03 2017 +1100 Closes: https://bugs.gentoo.org/629144 + + + + +Removing a virtual package + + + +Virtual packages are generally removed when they have no more than one +provider left. The removal is preceded by updating the remaining ebuilds +not to use the virtual. Since virtuals do not install any files, there +is little value in proactively forcing them to be uninstalled from user +systems or unnecessarily informing the user about the fact. Therefore, +an alternative removal process is recommended. + + + +In order to remove a virtual package, follow the following procedure: + + + + +If the virtual is being removed along with its second to last +provider, include the virtual in the last-rites mail. However, please +do not include it in the package.mask entry as users do not need +to be forced to proactively unmerge it. Instead, add it +to package.deprecated to warn developers not to depend on it. +Wait the time appropriate for the last rites. + + +Update all ebuilds not to reference the virtual. Since there is +no urgent need to remove the virtual from user systems +and the resulting rebuilds would be unnecessary, do not bump ebuilds +when replacing the dependency. + + +Remove the package directly + + +Perform the post-removal cleanup, as with regular packages + + + -- 2.28.0
