* [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
@ 2020-09-07 6:14 Michał Górny
2020-09-07 7:46 ` Ulrich Mueller
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Michał Górny @ 2020-09-07 6:14 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
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
</pre>
+</body>
+</section>
+
+<section>
+<title>Removing a virtual package</title>
+<body>
+
+<p>
+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.
+</p>
+
+<p>
+In order to remove a virtual package, follow the following procedure:
+</p>
+
+<ol>
+ <li>
+ 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 <c>package.mask</c> entry as users do not need
+ to be forced to proactively unmerge it. Instead, add it
+ to <c>package.deprecated</c> to warn developers not to depend on it.
+ Wait the time appropriate for the last rites.
+ </li>
+ <li>
+ 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.
+ </li>
+ <li>
+ Remove the package directly
+ </li>
+ <li>
+ Perform the post-removal cleanup, as with regular packages
+ </li>
+</ol>
+
</body>
</section>
</chapter>
--
2.28.0
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 6:14 [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal Michał Górny
@ 2020-09-07 7:46 ` Ulrich Mueller
2020-09-07 7:50 ` Michał Górny
2020-09-07 9:39 ` Kent Fredric
2020-09-07 11:32 ` Michael Orlitzky
2 siblings, 1 reply; 13+ messages in thread
From: Ulrich Mueller @ 2020-09-07 7:46 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
>>>>> On Mon, 07 Sep 2020, Michał Górny wrote:
> + <li>
> + 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 <c>package.mask</c> entry as users do not need
> + to be forced to proactively unmerge it. Instead, add it
> + to <c>package.deprecated</c> to warn developers not to depend on it.
> + Wait the time appropriate for the last rites.
> + </li>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 7:46 ` Ulrich Mueller
@ 2020-09-07 7:50 ` Michał Górny
0 siblings, 0 replies; 13+ messages in thread
From: Michał Górny @ 2020-09-07 7:50 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Mon, 2020-09-07 at 09:46 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 07 Sep 2020, Michał Górny wrote:
> > + <li>
> > + 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 <c>package.mask</c> entry as users do not need
> > + to be forced to proactively unmerge it. Instead, add it
> > + to <c>package.deprecated</c> to warn developers not to depend on it.
> > + Wait the time appropriate for the last rites.
> > + </li>
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 6:14 [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal Michał Górny
2020-09-07 7:46 ` Ulrich Mueller
@ 2020-09-07 9:39 ` Kent Fredric
2020-09-07 10:27 ` Alexis Ballier
2020-09-07 11:32 ` Michael Orlitzky
2 siblings, 1 reply; 13+ messages in thread
From: Kent Fredric @ 2020-09-07 9:39 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
On Mon, 7 Sep 2020 08:14:52 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> However, please
> + do not include it in the <c>package.mask</c> 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. :/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 9:39 ` Kent Fredric
@ 2020-09-07 10:27 ` Alexis Ballier
0 siblings, 0 replies; 13+ messages in thread
From: Alexis Ballier @ 2020-09-07 10:27 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, 7 Sep 2020 21:39:54 +1200
Kent Fredric <kentnl@gentoo.org> wrote:
> On Mon, 7 Sep 2020 08:14:52 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > However, please
> > + do not include it in the <c>package.mask</c> 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-----
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 6:14 [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal Michał Górny
2020-09-07 7:46 ` Ulrich Mueller
2020-09-07 9:39 ` Kent Fredric
@ 2020-09-07 11:32 ` Michael Orlitzky
2020-09-07 12:10 ` Ulrich Mueller
2 siblings, 1 reply; 13+ messages in thread
From: Michael Orlitzky @ 2020-09-07 11:32 UTC (permalink / raw
To: gentoo-dev
On 2020-09-07 02:14, Michał Górny wrote:
> + <li>
> + 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.
> + </li>
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 11:32 ` Michael Orlitzky
@ 2020-09-07 12:10 ` Ulrich Mueller
2020-09-07 12:18 ` Michael Orlitzky
2020-09-07 12:47 ` Alessandro Barbieri
0 siblings, 2 replies; 13+ messages in thread
From: Ulrich Mueller @ 2020-09-07 12:10 UTC (permalink / raw
To: Michael Orlitzky; +Cc: gentoo-dev
>>>>> On Mon, 07 Sep 2020, Michael Orlitzky wrote:
> On 2020-09-07 02:14, Michał Górny wrote:
>> + <li>
>> + 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.
>> + </li>
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 12:10 ` Ulrich Mueller
@ 2020-09-07 12:18 ` Michael Orlitzky
2020-09-07 12:30 ` Ulrich Mueller
2020-09-07 12:47 ` Alessandro Barbieri
1 sibling, 1 reply; 13+ messages in thread
From: Michael Orlitzky @ 2020-09-07 12:18 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 12:18 ` Michael Orlitzky
@ 2020-09-07 12:30 ` Ulrich Mueller
0 siblings, 0 replies; 13+ messages in thread
From: Ulrich Mueller @ 2020-09-07 12:30 UTC (permalink / raw
To: Michael Orlitzky; +Cc: gentoo-dev
>>>>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 12:10 ` Ulrich Mueller
2020-09-07 12:18 ` Michael Orlitzky
@ 2020-09-07 12:47 ` Alessandro Barbieri
2020-09-07 13:12 ` Ulrich Mueller
2020-09-07 13:21 ` Michael Orlitzky
1 sibling, 2 replies; 13+ messages in thread
From: Alessandro Barbieri @ 2020-09-07 12:47 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller <ulm@gentoo.org> 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.
[-- Attachment #2: Type: text/html, Size: 1323 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 12:47 ` Alessandro Barbieri
@ 2020-09-07 13:12 ` Ulrich Mueller
2020-09-07 13:21 ` Michael Orlitzky
1 sibling, 0 replies; 13+ messages in thread
From: Ulrich Mueller @ 2020-09-07 13:12 UTC (permalink / raw
To: Alessandro Barbieri; +Cc: gentoo-dev
>>>>> On Mon, 07 Sep 2020, Alessandro Barbieri wrote:
> Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller <ulm@gentoo.org> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 12:47 ` Alessandro Barbieri
2020-09-07 13:12 ` Ulrich Mueller
@ 2020-09-07 13:21 ` Michael Orlitzky
2020-09-07 13:56 ` Ulrich Mueller
1 sibling, 1 reply; 13+ messages in thread
From: Michael Orlitzky @ 2020-09-07 13:21 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
2020-09-07 13:21 ` Michael Orlitzky
@ 2020-09-07 13:56 ` Ulrich Mueller
0 siblings, 0 replies; 13+ messages in thread
From: Ulrich Mueller @ 2020-09-07 13:56 UTC (permalink / raw
To: Michael Orlitzky; +Cc: gentoo-dev
>>>>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-09-07 13:56 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-07 6:14 [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal Michał Górny
2020-09-07 7:46 ` Ulrich Mueller
2020-09-07 7:50 ` Michał Górny
2020-09-07 9:39 ` Kent Fredric
2020-09-07 10:27 ` Alexis Ballier
2020-09-07 11:32 ` Michael Orlitzky
2020-09-07 12:10 ` Ulrich Mueller
2020-09-07 12:18 ` Michael Orlitzky
2020-09-07 12:30 ` Ulrich Mueller
2020-09-07 12:47 ` Alessandro Barbieri
2020-09-07 13:12 ` Ulrich Mueller
2020-09-07 13:21 ` Michael Orlitzky
2020-09-07 13:56 ` Ulrich Mueller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox