Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
Control: tags -1 pending On 28-03-2019 01:22, vincent.mcint...@csiro.au wrote: > 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 From 6eb5bd59864b26b9b56b1e3b591e9e77cffef374 Mon Sep 17 00:00:00 2001 From: Paul Gevers Date: Thu, 28 Mar 2019 21:19:44 +0100 Subject: [PATCH] upgrading.dbk: improve wording around transitional dummy packages Closes: #901193 --- en/upgrading.dbk | 35 ++- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/en/upgrading.dbk b/en/upgrading.dbk index a22924f3..742b2d68 100644 --- a/en/upgrading.dbk +++ b/en/upgrading.dbk @@ -1311,24 +1311,25 @@ $ aptitude purge '~c' -Dummy packages - - Some packages from have been split into several packages in , often - to improve system maintainability. To ease the upgrade path in such cases, - often provides dummy packages: empty packages that have the same name as - the old package in with dependencies that cause the new packages to be - installed. These dummy packages are considered redundant after the - upgrade and can be safely removed. - - - Most (but not all) dummy packages' descriptions indicate their purpose. - Package descriptions for dummy packages are not uniform, however, so you might - also find deborphan with the +Transitional dummy packages + + Some packages from may have been replaced in + 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. + + + The package descriptions for transitional dummy packages usually indicate + their purpose. However, they are not uniform; in particular, some + dummy 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 deborphan with the --guess-* options (e.g. - --guess-dummy) 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. + --guess-dummy) useful to detect transitional dummy + packages on your system. -- 2.20.1 signature.asc Description: OpenPGP digital signature
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
On Thu, Mar 28, 2019 at 12:17:41AM +, Justin B Rye wrote: > vincent.mcint...@csiro.au wrote: > >> + > >> + The package descriptions for transitional dummy packages usually > >> indicate their > >> + purpose. However, they are not uniform; in particular, some > >> dummy > >> + 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 > >> + deborphan with the > >>--guess-* options > >> (e.g. > >> - --guess-dummy) 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. > >> + --guess-dummy) useful to detect transitional > >> dummy packages > >> + on your system. > >> > >> > >> > > > > 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 tracking packages, which are used to keep > > track of the current available version of a program over time. > > A common case is linux-image--. > > 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. > 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 > dummy > 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 > deborphan with the > --guess-* options (e.g. > --guess-dummy) useful to detect transitional dummy > packages > on your system. > Works for me. Vince
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
vincent.mcint...@csiro.au wrote: >> + >> + The package descriptions for transitional dummy packages usually >> indicate their >> + purpose. However, they are not uniform; in particular, some >> dummy >> + 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 >> + deborphan with the >>--guess-* options (e.g. >> - --guess-dummy) 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. >> + --guess-dummy) useful to detect transitional dummy >> packages >> + on your system. >> >> >> > > 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 tracking packages, which are used to keep > track of the current available version of a program over time. > A common case is linux-image--. 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 dummy 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 deborphan with the --guess-* options (e.g. --guess-dummy) useful to detect transitional dummy packages on your system. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
On Wed, Mar 27, 2019 at 11:34:20PM +, Ben Hutchings wrote: > On Wed, 2019-03-27 at 22:52 +, vincent.mcint...@csiro.au wrote: > [...] > > 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 tracking packages, which are used to keep > > track of the current available version of a program over time. > > A common case is linux-image--. > > 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. > > Ben. > > -- > Ben Hutchings > I say we take off; nuke the site from orbit. > It's the only way to be sure. > > --
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
On Wed, 2019-03-27 at 22:52 +, vincent.mcint...@csiro.au wrote: [...] > 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 tracking packages, which are used to keep > track of the current available version of a program over time. > A common case is linux-image--. Why do you want to introduce the term "tracking package" when we already have the term "metapackage"? Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
On Wed, Mar 27, 2019 at 02:23:41PM +, Justin B Rye wrote: > 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' > > > > -Dummy packages > - > - Some packages from have been split into several > packages in , often > - to improve system maintainability. To ease the upgrade path in such > cases, > - often provides dummy packages: empty > packages that have the same name as > - the old package in with dependencies that cause the > new packages to be > - installed. These dummy packages are considered > redundant after the > - upgrade and can be safely removed. > - > - > - Most (but not all) dummy packages' descriptions indicate their purpose. > - Package descriptions for dummy packages are not uniform, however, so > you might > - also find deborphan with the > +Transitional dummy packages > + > + Some packages from may have been replaced in > > + 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. > + > + > + The package descriptions for transitional dummy packages usually > indicate their > + purpose. However, they are not uniform; in particular, some > dummy > + 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 > + deborphan with the >--guess-* options (e.g. > - --guess-dummy) 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. > + --guess-dummy) useful to detect transitional dummy > packages > + on your system. > > > 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 tracking packages, which are used to keep track of the current available version of a program over time. A common case is linux-image--. Kind Regards Vince
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
Further thoughts on a revised version: > Dummy packages > > Some packages from have been split into several > packages in , often to improve system maintainability. To > ease the upgrade path in such cases, often provides > dummy packages: empty packages that have the same name as > the old package in with dependencies that cause the new > packages to be installed. These dummy packages are > considered redundant after the upgrade and can be safely removed. > 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. > > Most (but not all) dummy packages' descriptions indicate their > purpose. Package descriptions for dummy packages are not uniform, > however, so you might also find deborphan with the > --guess-* options (e.g. > --guess-dummy) 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. > > 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' -Dummy packages - - Some packages from have been split into several packages in , often - to improve system maintainability. To ease the upgrade path in such cases, - often provides dummy packages: empty packages that have the same name as - the old package in with dependencies that cause the new packages to be - installed. These dummy packages are considered redundant after the - upgrade and can be safely removed. - - - Most (but not all) dummy packages' descriptions indicate their purpose. - Package descriptions for dummy packages are not uniform, however, so you might - also find deborphan with the +Transitional dummy packages + + Some packages from may have been replaced in + 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. + + + The package descriptions for transitional dummy packages usually indicate their + purpose. However, they are not uniform; in particular, some dummy + 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 + deborphan with the --guess-* options (e.g. - --guess-dummy) 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. + --guess-dummy) useful to detect transitional dummy packages + on your system.
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
Paul Gevers wrote: > I wonder what is missing there from the perspective of this bug. The > section about dummy packages exists since before 2009 and currently reads: > ''' > Dummy packages > > Some packages from have been split into several > packages in , often to improve system maintainability. To > ease the upgrade path in such cases, often provides > dummy packages: empty packages that have the same name as > the old package in with dependencies that cause the new > packages to be installed. These dummy packages are > considered redundant after the upgrade and can be safely removed. > > > Most (but not all) dummy packages' descriptions indicate their > purpose. Package descriptions for dummy packages are not uniform, > however, so you might also find deborphan with the > --guess-* options (e.g. > --guess-dummy) 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. > > > ''' > > 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".) -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
Control: tags -1 moreinfo On Sun, 10 Jun 2018 02:15:51 +0100 Ben Hutchings wrote: > > 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: ''' Dummy packages Some packages from have been split into several packages in , often to improve system maintainability. To ease the upgrade path in such cases, often provides dummy packages: empty packages that have the same name as the old package in with dependencies that cause the new packages to be installed. These dummy packages are considered redundant after the upgrade and can be safely removed. Most (but not all) dummy packages' descriptions indicate their purpose. Package descriptions for dummy packages are not uniform, however, so you might also find deborphan with the --guess-* options (e.g. --guess-dummy) 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. ''' Suggestions on how to improve that text are welcome. Paul signature.asc Description: OpenPGP digital signature
