Re: Modifying a file from another package (rather than replacing it)
On Sun, Dec 26, 2010 at 02:10:08PM +0100, Malte Forkel wrote: > But, aside from the pbuilder specifics: Is there any policy, best > practice, or LSB scheme for extending an existing package? Are there any > hooks to re-apply changes to an existing package after it has been updated? > It definitively depends on the specific packageis. When ever it happened to me, I followed up all the maintainer(s) involved and we found all together a way to have a working pool of packages. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101227085648.ga2...@mithrandir
Re: Modifying a file from another package (rather than replacing it)
On 12/26/2010 02:10 PM, Malte Forkel wrote: > Am 25.12.2010 20:18, schrieb Michael Banck: >> >> Why can't this be part of pbuilder itself? Did your patches got >> rejected by the pbuilder author and if so, what was his rationale? >> Maybe if he thinks they should not be part of pbuilder, they shouldn't >> be part of another package either. >> > > I haven't attempted to submit my code yet. It works for me, but still > has to be cleaned up. Right now, I'm packaging it as a way of > documenting and organizing what I've done. > > But, aside from the pbuilder specifics: Is there any policy, best > practice, or LSB scheme for extending an existing package? Are there any > hooks to re-apply changes to an existing package after it has been updated? There is no such thing, though things that come close are: alternatives, hooks or config directories. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d175b42.7080...@debian.org
Re: Modifying a file from another package (rather than replacing it)
On Sun, 26 Dec 2010 14:10:08 +0100 Malte Forkel wrote: > But, aside from the pbuilder specifics: Is there any policy, best > practice, or LSB scheme for extending an existing package? Are there > any hooks to re-apply changes to an existing package after it has > been updated? Only if that package explicitly supports such mechanisms and only within the confines of what that extension mechanism can actually achieve. Once your changes exceed what the hooks can achieve, you can only expect to work with the developers of the other project upstream and co-operatively merge the two types of operation - or else fork the entire project and maintain all the code yourself. This kind of thing is common with embedded development, it's why we had a different version of dpkg-buildpackage, along with various other tools, as part of the dpkg-cross package for several stable releases until there was finally a version which could be merged back into dpkg itself and the outdated forks were dropped. Co-operate on a new version or fork the existing one - your choice. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpv2LgexXuBW.pgp Description: PGP signature
Re: Modifying a file from another package (rather than replacing it)
Am 25.12.2010 20:18, schrieb Michael Banck: > > Why can't this be part of pbuilder itself? Did your patches got > rejected by the pbuilder author and if so, what was his rationale? > Maybe if he thinks they should not be part of pbuilder, they shouldn't > be part of another package either. > I haven't attempted to submit my code yet. It works for me, but still has to be cleaned up. Right now, I'm packaging it as a way of documenting and organizing what I've done. But, aside from the pbuilder specifics: Is there any policy, best practice, or LSB scheme for extending an existing package? Are there any hooks to re-apply changes to an existing package after it has been updated? Malte -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/if7erb$5q...@dough.gmane.org
Re: Modifying a file from another package (rather than replacing it)
On Sat, Dec 25, 2010 at 07:53:41PM +0100, Malte Forkel wrote: > Am 25.12.2010 13:25, schrieb Ben Hutchings: > > If you cannot accomplish what you want using an existing hook then > > perhaps you should ask the pbuilder maintainer to add a new hook. > > Well, a new hook probably won't do. I've written to additional > "commands": buildmodule and buildootmodule. One patches and packages > single kernel modules, the other builds out-of-tree kernel modules with > module-assistant and dkms. In both cases, the idea is to do this for a > well-defined kernel, independent of the host machine's environment. Why can't this be part of pbuilder itself? Did your patches got rejected by the pbuilder author and if so, what was his rationale? Maybe if he thinks they should not be part of pbuilder, they shouldn't be part of another package either. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101225191804.ge25...@nighthawk.chemicalconnection.dyndns.org
Re: Modifying a file from another package (rather than replacing it)
Am 25.12.2010 13:25, schrieb Ben Hutchings: >> I've written a couple of extensions to pbuilder. When my package gets >> installed, a file from the pbuilder package (/usr/sbin/pbuilder) must be >> modified for my extension to work. I'm looking for the "proper" way to >> apply a patch to that file. > [...] > > This is not a good idea. What happens if the patch fails? What if two > packages try to patch pbuilder? The diversion is added in preinst and removed in postrm. The patch is applied in postinst. If the diversion fails, so does preinst, and postinst should not get called. So I only patch the file after it has been diverted to my package. I didn't find anything on dpkg-divert's return code in its man page. But from its source, I guess it exits with a non-zero status if you try to divert an already diverted file. What happens if the patch fails, I'm not that sure. Certainly, postinst fails. I would hope that this triggers postrm to be called with the about-install argument, which would remove the diversion. > > If you cannot accomplish what you want using an existing hook then > perhaps you should ask the pbuilder maintainer to add a new hook. Well, a new hook probably won't do. I've written to additional "commands": buildmodule and buildootmodule. One patches and packages single kernel modules, the other builds out-of-tree kernel modules with module-assistant and dkms. In both cases, the idea is to do this for a well-defined kernel, independent of the host machine's environment. Malte -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/if5ejh$37...@dough.gmane.org
Re: Modifying a file from another package (rather than replacing it)
On Sat, 2010-12-25 at 13:19 +0100, Malte Forkel wrote: > Hi (and happy hollidays)! > > I've written a couple of extensions to pbuilder. When my package gets > installed, a file from the pbuilder package (/usr/sbin/pbuilder) must be > modified for my extension to work. I'm looking for the "proper" way to > apply a patch to that file. [...] This is not a good idea. What happens if the patch fails? What if two packages try to patch pbuilder? If you cannot accomplish what you want using an existing hook then perhaps you should ask the pbuilder maintainer to add a new hook. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Modifying a file from another package (rather than replacing it)
Hi (and happy hollidays)! I've written a couple of extensions to pbuilder. When my package gets installed, a file from the pbuilder package (/usr/sbin/pbuilder) must be modified for my extension to work. I'm looking for the "proper" way to apply a patch to that file. I would like to patch rather than just replace the file because I don't want to overwrite any changes to the file that might come with newer versions of the original package. Ideally, I would even like to reapply my patch whenever a different version of the file gets installed by a new version of original package. How do I do this from my package's maintainer scripts? I thought I could use a diversion for the original file in preinst and then patch a copy of it in postinst. But where should I (temporarily?) install the patchfile? And is there any way to automatically have that patch reapplied when a new version of the original file is installed? Thanks, Malte -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/if4ngg$kg...@dough.gmane.org
