Re: Transitional packages: unmark auto, dealing with conffiles
On Mon, Dec 19, 2011 at 22:08, Malte Forkel <malte.forkel@berlin.de> wrote:
> Lenny? I have tested clearing the flag in '/var/lib/apt/extended_state'
> from the postinst script of the transitional package. But aptitude will
> override this by setting the flag later during the upgrade. And its a
> hack, anyway.
It's not only aptitude, every package manager using libapt will hate
you for this - and therefore i will hate you; even on Christmas. ;)
In general, you should NEVER touch a file belonging to another package
as you never know if it will be there and which format it has --
and for /var/lib files is this especially true as they are state files.
Regarding Lenny: Just don't care anymore. Security support ends in due
time, so don't try to support unsupported channels. Users of these old
systems will have bigger problems than the inability to install your package
(and that's not even the problem you seem to deal with…).
If you really really really have to do it, "just" copy the relevant code from
the helpers, they aren't magic after all, but make sure to test it carefully!
> Regarding the configuration files, I know now that newer versions of
> dpkg include 'dpkg-maintscript-helper' with commands to move or remove
> conffiles. This works nicely in Squeeze. But again, how can I support
> systems with Lenny? In order to make the transitional package forget
> about a conffile, I tested removing it in the package's postinst script
> and also remove the corresponding entry from
> /var/lib/dpkg/info/<package>.list. That seems to work, but I would
> consider it a hack as well.
Same comment regarding lenny. Same about file-edit hacks.
Add a realworld example to this as dpkg will change info/ filenames
(for at least some packages) with the introduction of multiarch.
> I have found the interesting thread 'Transitional (dummy) packages
> considered silly' on Debian Devel
> (http://lists.debian.org/debian-devel/2009/09/msg00687.html). Will any
> of the suggestions made there make it into Debian? E.g., how about a new
> control field 'Superseeds'?
Have you read some of the responses? Looks like you haven't
as a few counterarguments are given in this thread like blocking
the "old" name even longer, could allow social fights like chromium
superseeds iceweasel or kde superseeds gnome and in general allows
any maintainer to install his package without direct user interaction.
If you think that is too unlikely, think about situations in which a program
changes drastically from v1 to v2 and a fork tries to maintain v1.
Does this fork now superseed v1 of the program or is it v2 ?
(e.g. amarok vs. clementine or in the old thread apache vs apache2)
Also, what should be done if two packages claim to superseed the
same package? And what happens if a rename is reverted?
Or the next stable release carries a new package with the superseeded
name, thinking e.g. about the git: gnuit vs git-core name-collision.
Also, think about an application which changes his program name, but to
allow a soft transition, the transistional package provides a wrapper
with the old name. Clearly the new superseeds the old, but removing the
old still removes functionality…
Way to complex for such a small usecase in my eyes. Properly better
to invest the time to make "disappearing packages" policy-compatible
and usable instead. In the easy cases libapt users even transfer the
auto-bit to the replacer…
Best regards
David Kalnischkies
Reply to: