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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f097f7a.4010...@berlin.de
Re: Transitional packages: unmark auto, dealing with conffiles
On Mon, Dec 19, 2011 at 22:08, Malte Forkel malte.for...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fc-xbwqnbdewnsqfpb4pbq5udtpeqcijjyyv76feih...@mail.gmail.com
Transitional packages: unmark auto, dealing with conffiles
Hello, I am writing a transitional package to handle a software name change. There are two problems I'm trying to handle: - How to avoid marking the new package (which the transitional package depends upon) as being autoinstalled. - How to deal with old conffiles not adopted by the new package. I have posed these two questions before, one on Debian User (http://lists.debian.org/debian-user/2011/12/msg00739.html), one on Debian Devel (http://lists.debian.org/debian-devel/2011/12/msg00337.html). In both cases, I have received helpful advice and the suggestion to pose these questions on Debian Mentors. So I'll recap what I have learned so far and hope you can fill in the mising pieces. Regarding the unmark auto flag, I know now that newer versions of apt will not mark packages as auto if they are autoinstalled due to a package in section 'oldlibs' or 'metapackages'. So, if the transitional package belongs to one of those two and gets installed by 'apt-get dist-upgrade' in Squeeze, everything is fine. But what if another tool is used, e.g. aptitude. And how can I support people still running 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. 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. 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'? There are probably more questions regarding transitional packages than the two I have come across so far. It seems to me there could be better support for transitional packages in Debian in terms of policy, tool support and documentation. What are your thoughts? Of course, I'd be happy to help in bringing these issues along. Thanks, Malte -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jco94f$3aj$1...@dough.gmane.org
transitional packages
Hello. How to make transitional packages with cdbs? I tried to simply add an extra package in control, that depends on new package. But CDBS then moves some files (the main binary also) in debian/tmp instead of debian/ newpackagename and doesn't include them in package. :( -- Dan Korostelev [EMAIL PROTECTED]
Re: transitional packages
Le dim, 04/07/2004 à 02:40 +0400, Dan Korostelev a écrit : Hello. How to make transitional packages with cdbs? I tried to simply add an extra package in control, that depends on new package. But CDBS then moves some files (the main binary also) in debian/tmp instead of debian/ newpackagename and doesn't include them in package. :( Hi, The files are installed in debian/tmp and then moved according to the packages.install files. So you need to create a newpackagename.install with the content of newpackagename. An example of .install (the lines need to start with debian/tmp): debian/tmp/usr/lib/*.so debian/tmp/usr/include Cheers, Sebastien Bacher
Re: transitional packages
В сообщении от Вск, 2004-07-04 at 00:53 +0200, Sebastien Bacher писал: The files are installed in debian/tmp and then moved according to the packages.install files. So you need to create a newpackagename.install with the content of newpackagename. An example of .install (the lines need to start with debian/tmp): debian/tmp/usr/lib/*.so debian/tmp/usr/include Okay, thanks, it worked! -- Dan Korostelev [EMAIL PROTECTED]
transitional packages
Hello. How to make transitional packages with cdbs? I tried to simply add an extra package in control, that depends on new package. But CDBS then moves some files (the main binary also) in debian/tmp instead of debian/ newpackagename and doesn't include them in package. :( -- Dan Korostelev [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transitional packages
Le dim, 04/07/2004 à 02:40 +0400, Dan Korostelev a écrit : Hello. How to make transitional packages with cdbs? I tried to simply add an extra package in control, that depends on new package. But CDBS then moves some files (the main binary also) in debian/tmp instead of debian/ newpackagename and doesn't include them in package. :( Hi, The files are installed in debian/tmp and then moved according to the packages.install files. So you need to create a newpackagename.install with the content of newpackagename. An example of .install (the lines need to start with debian/tmp): debian/tmp/usr/lib/*.so debian/tmp/usr/include Cheers, Sebastien Bacher
Re: transitional packages
, 2004-07-04 at 00:53 +0200, Sebastien Bacher : The files are installed in debian/tmp and then moved according to the packages.install files. So you need to create a newpackagename.install with the content of newpackagename. An example of .install (the lines need to start with debian/tmp): debian/tmp/usr/lib/*.so debian/tmp/usr/include Okay, thanks, it worked! -- Dan Korostelev [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
