On Mon, Dec 19, 2011 at 22:08, Malte Forkel <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/caaz6_fc-xbwqnbdewnsqfpb4pbq5udtpeqcijjyyv76feih...@mail.gmail.com
