[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Further thoughts on a revised version:
>     <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.

>     <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...
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package
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>
 

Reply to: