Re: Transitional packages: unmark auto, dealing with conffiles
Am 24.12.2011 12:23, schrieb David Kalnischkies:
> It's not only aptitude, every package manager using libapt will hate
> you for this - and therefore i will hate you; even on Christmas. ;)
I wouldn't want you to hate me. At least not 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.
I agree that modifying other packages' files is a bad idea. That's why I
called it a hack. My hope was that someone could show me a clean,
policy-consistent way to solve the problems I encountered when trying to
provide a transitional package.
>> 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.
Let's just assume that we both have read the whole thread ;-).
I guess how one weighs the different arguments heavily depends on one's
own background and preferences. My impression was that most posters
eventually liked the ideas of a superseeds relationship. But by no means
would I claim to know what the Debian policy on transitional packages
should look like. I'm just a spare time package maintainer trying to
entice the Debian gods to come up with a solution.
One reason why I like Debian is that it tries to do things "the right
way". To me, that includes making things explicit and documenting them
in the policy. If a package management use case requires using scarcely
documented features or even hacking, then I'm confident the Debian
community can up with a better solution.
I think, the existing approach to transitional packages involves too
many implicit solutions, e.g. using special sections or relying on
keywords in a package's description. It would be great if the support
provided by apt could be reviewed, potentially extended, documented in
the Debian policy and the wiki, and adopted by all package mamangement
tools.
> 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…
It seems to me that potential solutions to some of your caveats were
suggested in the original thread. And no package maintainer would be
forced to use the superseeds relationship. What has worked in the past
does not have to be changed.
But we might have to ask: How do we handle these cases now? And if a
policy extension could solve some of the existing problems (e.g. auto
install bit tansfer, configuration file transition), would it introduce
bigger problems elsewhere?
We can't prevent misuse, though. I don't need a superseeds relationship
to create havoc. E.g., I could simply modify other package's files... ;-)
Let's just try to find the best overall solution. Should it include a
superseeds relationship? I don't know.
> 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…
Well, why not do both?
Malte
Reply to: