On Sun, Jan 17, 2016 at 11:40:34PM +0100, gregor herrmann wrote:
> I was curious if I can reproduce this issue [0]:
>
> - jessie chroot (from cowbuilder)
> - rm /etc/apt/apt.conf.d/15pbuilder
> (APT::Install-Recommends "false";)
> - aptitude install libmodule-build-perl+M
> - make sure libmodule-build-perl is really marked auto
> - sed -i -e 's/jessie/stretch/g' /etc/apt/sources.list
> - aptitude update
> - aptitude dist-upgrade
> - allow aptitude to remove perl-modules
> - let the upgrade run
>
> Result:
> libmodule-build-perl is still installed at this point. Good.
> Opening aptitudes TUI then suggests to remove a bunch of perl
> packages, among them libmodule-build-perl. Bad.
>
> Without aptitude:
> - jessie chroot (from cowbuilder)
> - rm /etc/apt/apt.conf.d/15pbuilder
> (APT::Install-Recommends "false";)
> - apt-get install libmodule-build-perl
> - apt-mark auto libmodule-build-perl
> - sed -i -e 's/jessie/stretch/g' /etc/apt/sources.list
> - apt-get update
> - apt-get dist-uprade
>
> Result:
> This throws away some automatically installed packages but not
> libmodule-build-perl. Good.
> apt-get autoremove then removes it. Bad.
Or to put it another way: system working as designed. This isn't
a problem with the tools, it's that at the end of the day there
is no real way to express that a package is being split out from
another one.
If someone has the energy to propose a Recommends-like field which is
'sticky' during upgrades, that would be an interesting discussion to have.
The problem is that it would be a field which would introduce some
weird unreproducibility - because a system seeded with a fixed set of
manually requested packages at different times would result in a
different set of installed packages; which seems contrary to the
spirit of the thing.
> The interesting point is that in both cases, libmodule-build-perl is
> _not_ removed during the dist-upgrade. But it's "marked" as a removal
> candidate and would need manual intervention to keep it.
>
>
> For the future we might try to remember that having a Recommends in a
> package which gets removed leaves the recommended package in an
> "orphaned" state from the POV of apt{itude,-get}.
> (In this case, IIRC, the decision to replace perl-modules by a
> versioned package came only after the jessie release ...)
I don't think we can really do more than we already do - although
in this particular case, having dh-make-perl depend on
libmodule-build-perl as you suggested latest wouldn't be a bad idea.
Cheers,
Dominic.
