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/ > 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 .install with the content of . 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 .install > with the content of . > 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]>
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/ > 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 .install with the content of . 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 .install > with the content of . > 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]
Re: Transitional packages: unmark auto, dealing with conffiles
On Mon, Dec 19, 2011 at 22:08, Malte Forkel 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/.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
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