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

Re: cleanly getting rid of manually installed transitional packages due to rename



On Fri 24 Apr 2020 at 21:07:31 (+0200), Vincent Lefevre wrote:

> Since you don't want to purge pdftk, why did you decide to purge it
> above?

Because in Real Life, pdftk is an empty transitional package.
In your hypothetical example you said it wasn't. So you shouldn't
be surprised that its fate will be different. I did warn you that
using the same names would cause confusion.

My example was real, where a package with one name (pdftk) is replaced
by another with a different name (pdftk-java). The situation is simple
enough that it would be straightforward to script it, which was my point.

I've no idea your example was intended to show, because it's
ambiguous, but I assume there was a reason behind it. I will
redescribe it in simple terms from your description, and then
it will be easier for you to indicate your reasoning.

> On 2020-04-23 13:59:29 -0500, David Wright wrote:
> > On Thu 23 Apr 2020 at 02:53:06 (+0200), Vincent Lefevre wrote:
> > > On 2020-04-22 16:07:28 -0500, David Wright wrote:
> > > > For trivial renames, which yours looks like, as do those I've done,
> > > > it would be pretty easy to script. I've never made the effort,
> > > > because it's not something I do frequently enough, usually just once,
> > > > soon after I start running a new release on the first computer. Then
> > > > I adjust the list of packages used for the rest of them. Manually:
> > > > 
> > > >  $ apt-get -s purge pdftk
> > > >  The following package was automatically installed and is no longer required:
> > > >   pdftk-java
> > > >  Use 'apt autoremove' to remove it.
> > > >  # apt-mark manual pdftk-java
> > > >  pdftk-java set to manually installed.
> > > >  $ apt-get -s purge pdftk
> > > >  # apt-get purge pdftk
> > > >  Removing pdftk (2.02-5) ...
> > > > 
> > > > (Routine output edited out.) The first step can list more packages,
> > > > so checking the Depends line for the original package should show
> > > > which is the replacement.
> > > 
> > > I think that you are over-optimistic. Imagine the following case.
> > > The pdftk package has been manually installed in the past and is
> > > not a transitional package to pdftk-java

OK, so using pdftk≡PkgA and pdftk-java≡PkgB, we have

• PkgA, manual, depends on PkgB, performs FunctionF1, not transitional.

• PkgB, automatic, required by PkgA, performs FunctionF2.

> > > (currently, this is like
> > > your example).

Somewhat alike, but not exactly the same. My real example would be
written as
    PkgA, manual, depends on PkgB, performs nothing (transitional).
    PkgB, automatic, required by PkgA, performs FunctionF.
when expressed in these terms.

> > > But the system has some package that depends on
> > > pdftk-java.

Let's call the "some package" PkgC, and we don't know what it does
or whether it's manual or automatic.

• PkgC, depends on PkgB. Function unspecified.

We now have to modify PkgB as well.

• PkgB, automatic, required by PkgA, required by PkgC, performs FunctionF2.

> > > So, when you run
> > > 
> > >   apt-get -s purge pdftk
> > > 
> > > you won't have any message about pdftk-java.

What is your reason for suggesting that I should run
"apt-get -s purge PkgA" because I can't think of one.
(You did say that PkgA is *not* transitional.)

> Since you don't want to purge pdftk,

Correct, I do not want to purge the hypothetical PkgA (as it still
performs FunctionF1).

> why did you decide to purge it
> above?

Because the real pdftk in my example above *was* transitional,
and in buster it has no function: it's empty¹.

> > > Later in the future,
> > > the dependency on pdftk-java disappears, so that pdftk-java will
> > > be proposed for autoremoval.

You've used some ambiguous language here. Your hypothetical scenario
is currently:

• PkgA, manual, depends on PkgB, performs FunctionF1, not transitional.
• PkgB, automatic, required by PkgA, required by PkgC, performs FunctionF2.
• PkgC, depends on PkgB. Function unspecified.

Which dependent relationship(s) do you want to make disappear in the
future? After you've decided on that, perhaps we can discuss whatever
it is that I'm meant to forget about PkgA, in your hypothetical scenario.


¹
Buster's pdftk (on another host) can be seen to have no function:

$ dpkg -L pdftk
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/pdftk
/usr/share/doc/pdftk/NEWS.Debian.gz
/usr/share/doc/pdftk/changelog.Debian.gz
/usr/share/doc/pdftk/changelog.gz
/usr/share/doc/pdftk/copyright
$ 

Cheers,
David.


Reply to: