Processed: Re: Bug#901003: There is no standard way of removing transitional / dummy packages

[Debian Bug Tracking System]

clone -1 -2

Bug #901003 [debian-handbook] There is no standard way of removing transitional / dummy packages
Bug 901003 cloned as bug 901193

reassign -2 release-notes

Bug #901193 [debian-handbook] There is no standard way of removing transitional / dummy packages
Bug reassigned from package 'debian-handbook' to 'release-notes'.
Ignoring request to alter found versions of bug #901193 to the same values previously set
Ignoring request to alter fixed versions of bug #901193 to the same values previously set

[Debian Bug Tracking System]

tags -1 moreinfo

Bug #901193 [release-notes] There is no standard way of removing transitional / dummy packages
Added tag(s) moreinfo.

[Paul Gevers]

Control: tags -1 moreinfo

Perhaps a better location would be the upgrading chapter of the release
notes? [1]
That includes various things that one can do to clean up your system
after the upgrade; removing transitional packages would seem like a good
thing to do at that point.
[1] https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#for-next

That would also be a good place.

I wonder what is missing there from the perspective of this bug. The
section about dummy packages exists since before 2009 and currently reads:
'''
<title>Dummy packages</title>
<para>
Some packages from &oldreleasename; have been split into several
packages in &releasename;, often to improve system maintainability. To
ease the upgrade path in such cases, &releasename; often provides
<quote>dummy</quote> packages: empty packages that have the same name as
the old package in &oldreleasename; with dependencies that cause the new
packages to be installed. These <quote>dummy</quote> packages are
considered redundant after the upgrade and can be safely removed.
</para>
<para>
Most (but not all) dummy packages' descriptions indicate their
purpose. Package descriptions for dummy packages are not uniform,
however, so you might also find <command>deborphan</command> with the
<literal>--guess-<replaceable>*</replaceable></literal> options (e.g.
<literal>--guess-dummy</literal>) useful to detect them in your system.
Note that some dummy packages are not intended to be removed after an
upgrade but are, instead, used to keep track of the current available
version of a program over time.
</para>
</section>
'''

Suggestions on how to improve that text are welcome.

Paul

[Justin B Rye]

Post by Paul Gevers
I wonder what is missing there from the perspective of this bug. The
'''
<title>Dummy packages</title>
<para>
Some packages from &oldreleasename; have been split into several
packages in &releasename;, often to improve system maintainability. To
ease the upgrade path in such cases, &releasename; often provides
<quote>dummy</quote> packages: empty packages that have the same name as
the old package in &oldreleasename; with dependencies that cause the new
packages to be installed. These <quote>dummy</quote> packages are
considered redundant after the upgrade and can be safely removed.
</para>
<para>
Most (but not all) dummy packages' descriptions indicate their
purpose. Package descriptions for dummy packages are not uniform,
however, so you might also find <command>deborphan</command> with the
<literal>--guess-<replaceable>*</replaceable></literal> options (e.g.
<literal>--guess-dummy</literal>) useful to detect them in your system.
Note that some dummy packages are not intended to be removed after an
upgrade but are, instead, used to keep track of the current available
version of a program over time.
</para>
</section>
'''
Suggestions on how to improve that text are welcome.

One thing it doesn't have is any mention of the word "transitional",
which is the one you're actually better off searching for.

(It might also usefully end by referring to the *other* sort of dummy
packages as "dependency metapackages".)

[Justin B Rye]

Post by Paul Gevers
<title>Dummy packages</title>
<para>
Some packages from &oldreleasename; have been split into several
packages in &releasename;, often to improve system maintainability. To
ease the upgrade path in such cases, &releasename; often provides
<quote>dummy</quote> packages: empty packages that have the same name as
the old package in &oldreleasename; with dependencies that cause the new
packages to be installed. These <quote>dummy</quote> packages are
considered redundant after the upgrade and can be safely removed.
</para>

This talks as if package *splits* are the normal reason for
transitional dummy packages. Is that even true? The only specific
case I remember running into for my trial Stretch/Buster upgrades is
apt-transport-https, where on the contrary the reason the package has
become redundant is that its functions have been absorbed into the
main package.

Instead of starting from the developer's point of view and talking
about package-maintenance workflows that can result in the existence
of transitional packages, we should start by describing the symptoms
visible to end users: a package that was directly useful in Stretch
has become a redundant placeholder in Buster.

Post by Paul Gevers
<para>
Most (but not all) dummy packages' descriptions indicate their
purpose. Package descriptions for dummy packages are not uniform,
however, so you might also find <command>deborphan</command> with the
<literal>--guess-<replaceable>*</replaceable></literal> options (e.g.
<literal>--guess-dummy</literal>) useful to detect them in your system.
Note that some dummy packages are not intended to be removed after an
upgrade but are, instead, used to keep track of the current available
version of a program over time.
</para>
</section>

I hadn't noticed that deborphan *also* chooses to standardise on the
term "dummy". It's true that apt-transport-https is a dummy package;
unfortunately, *all* metapackages are empty placeholder dummy-packages
(and some of them use the word "dummy" in their descriptions), so a
command "deborphan --guess-dummy" really ought to find games-all and
linux-image-amd64 and erlang as well. The thing that's special about
apt-transport-https is that it's a *transitional* package.

If only debtags had been competently implemented this would all have
been solved a decade ago...

[V***@csiro.au]

diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index a22924f3..37fa449d 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -1311,24 +1311,25 @@ $ aptitude purge '~c'
</para>
<section id="dummy">
- <title>Dummy packages</title>
- <para>
- Some packages from &oldreleasename; have been split into several packages in &releasename;, often
- to improve system maintainability. To ease the upgrade path in such cases,
- &releasename; often provides <quote>dummy</quote> packages: empty packages that have the same name as
- the old package in &oldreleasename; with dependencies that cause the new packages to be
- installed. These <quote>dummy</quote> packages are considered redundant after the
- upgrade and can be safely removed.
- </para>
- <para>
- Most (but not all) dummy packages' descriptions indicate their purpose.
- Package descriptions for dummy packages are not uniform, however, so you might
- also find <command>deborphan</command> with the
+ <title>Transitional dummy packages</title>
+ <para>
+ Some packages from &oldreleasename; may have been replaced in &releasename;
+ by transitional dummy packages, which are empty placeholders designed to
+ simplify upgrades. If for instance an application that was formerly a single
+ package has been split into several, a transitional package may be provided
+ with the same name as the old package and with appropriate dependencies to
+ cause the new ones to be installed. After this has happened the redundant
+ dummy package can be safely removed.
+ </para>
+ <para>
+ The package descriptions for transitional dummy packages usually indicate their
+ purpose. However, they are not uniform; in particular, some <quote>dummy</quote>
+ packages are designed to be kept installed (e.g. to express a dependency on
+ the current latest version of some program). You might also find
+ <command>deborphan</command> with the
<literal>--guess-<replaceable>*</replaceable></literal> options (e.g.
- <literal>--guess-dummy</literal>) useful to detect them in your system. Note
- that some dummy packages are not intended to be removed after an upgrade but
- are, instead, used to keep track of the current available version of a program
- over time.
+ <literal>--guess-dummy</literal>) useful to detect transitional dummy packages
+ on your system.
</para>
</section>

I agree with everything you've said about this text but as regards
the patch I think some mention of tracking packages should be kept.
Something like:

One class of dummy package that are not intended to be removed
are <quote>tracking</quote> packages, which are used to keep
track of the current available version of a program over time.
A common case is <literal>linux-image-</literal>-&architecture;.

Kind Regards
Vince

[Ben Hutchings]

On Wed, 2019-03-27 at 22:52 +0000, ***@csiro.au wrote:
[...]

Post by V***@csiro.au
I agree with everything you've said about this text but as regards
the patch I think some mention of tracking packages should be kept.
One class of dummy package that are not intended to be removed
are <quote>tracking</quote> packages, which are used to keep
track of the current available version of a program over time.
A common case is <literal>linux-image-</literal>-&architecture;.

Why do you want to introduce the term "tracking package" when we
already have the term "metapackage"?

Ben.

[V***@csiro.au]

Post by Ben Hutchings
[...]

Post by V***@csiro.au
I agree with everything you've said about this text but as regards
the patch I think some mention of tracking packages should be kept.
One class of dummy package that are not intended to be removed
are <quote>tracking</quote> packages, which are used to keep
track of the current available version of a program over time.
A common case is <literal>linux-image-</literal>-&architecture;.

Why do you want to introduce the term "tracking package" when we
already have the term "metapackage"?

That was the term I was looking for, thank you.

Post by Ben Hutchings
Ben.
--
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.

--

[Justin B Rye]

Post by V***@csiro.au

+ <para>
+ The package descriptions for transitional dummy packages usually indicate their
+ purpose. However, they are not uniform; in particular, some <quote>dummy</quote>
+ packages are designed to be kept installed (e.g. to express a dependency on
+ the current latest version of some program). You might also find
+ <command>deborphan</command> with the
<literal>--guess-<replaceable>*</replaceable></literal> options (e.g.
- <literal>--guess-dummy</literal>) useful to detect them in your system. Note
- that some dummy packages are not intended to be removed after an upgrade but
- are, instead, used to keep track of the current available version of a program
- over time.
+ <literal>--guess-dummy</literal>) useful to detect transitional dummy packages
+ on your system.
</para>
</section>

I agree with everything you've said about this text but as regards
the patch I think some mention of tracking packages should be kept.
One class of dummy package that are not intended to be removed
are <quote>tracking</quote> packages, which are used to keep
track of the current available version of a program over time.
A common case is <literal>linux-image-</literal>-&architecture;.

The idea was that the earlier bit about "a dependency on the current
latest version of some program" was talking about "tracking packages",
and it seemed to make more sense to mention them in the part before
the deborphan recipe.

Unlike Ben I rather like the idea of distinguishing version-tracking
dependency metapackages from full-suite dependency metapackages, but
we don't want to go into it in depth here. The objective is just to
tell readers enough to let them ignore both kinds while searching for
transitional dummy packages.

I was deliberately not using linux-image-* as an example on the
grounds that it doesn't claim to be a "dummy package". In fact most
of the confusing cases seem to be "full-suite" metapackages.

So another option would be:

The package descriptions for transitional dummy packages usually indicate their
purpose. However, they are not uniform; in particular, some <quote>dummy</quote>
packages are designed to be kept installed, in order to pull in a full software
suite, or track the current latest version of some program. You might also find
<command>deborphan</command> with the
<literal>--guess-<replaceable>*</replaceable></literal> options (e.g.
<literal>--guess-dummy</literal>) useful to detect transitional dummy packages
on your system.

[V***@csiro.au]

Post by Justin B Rye

Post by V***@csiro.au

+ <para>
+ The package descriptions for transitional dummy packages usually indicate their
+ purpose. However, they are not uniform; in particular, some <quote>dummy</quote>
+ packages are designed to be kept installed (e.g. to express a dependency on
+ the current latest version of some program). You might also find
+ <command>deborphan</command> with the
<literal>--guess-<replaceable>*</replaceable></literal> options (e.g.
- <literal>--guess-dummy</literal>) useful to detect them in your system. Note
- that some dummy packages are not intended to be removed after an upgrade but
- are, instead, used to keep track of the current available version of a program
- over time.
+ <literal>--guess-dummy</literal>) useful to detect transitional dummy packages
+ on your system.
</para>
</section>

I agree with everything you've said about this text but as regards
the patch I think some mention of tracking packages should be kept.
One class of dummy package that are not intended to be removed
are <quote>tracking</quote> packages, which are used to keep
track of the current available version of a program over time.
A common case is <literal>linux-image-</literal>-&architecture;.

The idea was that the earlier bit about "a dependency on the current
latest version of some program" was talking about "tracking packages",
and it seemed to make more sense to mention them in the part before
the deborphan recipe.

Ah, with you now. sorry for the noise.

Post by Justin B Rye
Unlike Ben I rather like the idea of distinguishing version-tracking
dependency metapackages from full-suite dependency metapackages, but
we don't want to go into it in depth here. The objective is just to
tell readers enough to let them ignore both kinds while searching for
transitional dummy packages.
I was deliberately not using linux-image-* as an example on the
grounds that it doesn't claim to be a "dummy package". In fact most
of the confusing cases seem to be "full-suite" metapackages.
The package descriptions for transitional dummy packages usually indicate their
purpose. However, they are not uniform; in particular, some <quote>dummy</quote>
packages are designed to be kept installed, in order to pull in a full software
suite, or track the current latest version of some program. You might also find
<command>deborphan</command> with the
<literal>--guess-<replaceable>*</replaceable></literal> options (e.g.
<literal>--guess-dummy</literal>) useful to detect transitional dummy packages
on your system.

Works for me.
Vince

[Paul Gevers]

Control: tags -1 pending

Post by V***@csiro.au
Works for me.

And for me. So I have locally committed the attached changes which I
will push if no comments appear in the next two days.

Paul

[Debian Bug Tracking System]

Post by Paul Gevers
tags -1 pending

Bug #901193 [release-notes] There is no standard way of removing transitional / dummy packages
Added tag(s) pending.

[Debian Bug Tracking System]

Your message dated Sun, 31 Mar 2019 14:33:40 +0200
with message-id <82c89645-ea22-a92d-86d0-***@debian.org>
and subject line Re: Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
has caused the Debian Bug report #901193,
regarding There is no standard way of removing transitional / dummy packages
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)