[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Patch²: Maintaining a patch for a debian package

Hi, Sylvain:

El Viernes, 16 Septiembre 2005 16:12, Sylvain Beucler escribió:
> Hello,
> I have a couple Debian packages that I need to patch with custom local
> changes. The patches are small and I hence can follow the security
> updates from the security team.
> However, I wonder if there's already a way to automatically manage
> such kind of packages.


Now, just for the record, I'll expand on what I think should have to be "the 
proper way", so someone else could explain best practices or suggest what can 
be done.

We all know there are "source" and "binary" distributions, and more or less we 
are aware of the benefits and problems about both of them.  Now comes what I 
think it is quite a usual scenario:

I want a binary distribution since it makes easier to me (the end user) to 
maintain my box and, at the same time, I can be more confident about the 
stability of the resultset, since those same binaries are installed on about 
a tonn of different computers.

Now, it tend to happen that on any given computer I want/need just a few 
packages to be built from sources, because some patches I should apply, some 
changes I need to introduce, compiling options... whatever.

I, of course, can grab the tarballs from the upside developer and compile them 
locally, but then I cannot benefit from the advantages of having all software 
under the package manager control.

I can, then, download the source packages from my distribution, expand, patch, 
modify... and then install my new local package (the situation of the parent 
poster) but...

1) I may leave all metadata as it came from the source package, but then, the 
package manager will "upgrade" it next time a new version is available, thus 
loosing my modifications.
2) I may change metadata for my package (either its name, its upstream 
version, its build version, or whatever), but then, when a new version is 
available from repositories (ie: a new security upgrade) I won't be aware of 
this, since for the package manager they will be either in different "package 
branches" or current installed version will be higher than that from the 
repos, or I'll be on situation 1) if my local package happens to have lesser 
precedence than the one from the public repo.

So, I think I want a mixed source/binary packager manager.

An example:

Current OS version on my computer is Sarge.  Let's imagine I patched and 
recompiled Postfix (this is an interesting package since it builds half a 
dozen different packages from a single source package).

Currently Sarge holds Postfix 2.1.5-9.

Now, let's imagine a new security fix for Postfix is produced (it should be, I 
think, Postfix 2.1.5-9sarge1)

I would want something like this:
# apt-get update
# apt-get dist-upgrade
Packages foo, bar (...) Postfix are going to be upgraded.
Postfix was locally build from sources.  Do you want to
(H)old your current version?
(U)pgrade from Sarge repositories?
Try to (M)erge changes and rebuild? (h|u|M)?

Then, I choose "M" and apt downloads new sources, tries to merge upstream and 
local changes (offering the option to manually manage the merge if needed), 
builds and installs.

By the day Etch becomes stable, my patch has been added to Etch's Postfix 
version, so there's no further need for me to maintain my own package. Then 
it should be able for me to "mark" it and abandon (maybe, by choosing the "U" 
option when upgrading).

Now, what's the way to achieve what I propose, if possible, or what should 
have to be done in order to get to this in the future?

Reply to: