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?
--
SALUD,
Jesús
Reply to: