Debian way to make tiny change to package
Posted by StephenBenoit on Wed 24 Oct 2007 at 10:30
Have you ever had to make a one-line correction (or customization) in a big package? If so how did you manage it? The obvious way is to rebuild a package and serve it locally, but is there some other approach?
After spending an hour investigating bad behavior from the amoverview perl script in the amanda-server package (2.5.1p1-2.1), I traced the problem to one line in the script. It was an easy fix if you don't mind tweaking code directly in /usr/sbin/.
For those who are interested: the diff is:
--- /usr/sbin/amoverview- 2006-11-28 20:17:23.000000000 -0500
+++ /usr/sbin/amoverview 2007-10-22 11:16:39.000000000 -0400
@@ -126,7 +126,7 @@
next if /found Amanda directory/;
next if /skipping cruft directory/;
next if /skip-incr/;
- ($date, $host, $disk, $level, $tape, $file, $part, $status) = quotewords(" ", 0, $_);
+ ($date, $host, $disk, $level, $tape, $file, $part, $status) = quotewords('\s+', 0, $_);
next if $date eq 'date';
next if $date eq 'Warning:';
next if $date eq 'Scanning';
But now the fun part. How should we take this change and distribute it over the other hosts on my network? I usually rebuild a package and assign it a newer version or patchlevel. But amanda-server is a hefty package and I hesitate at installing all the packages required for rebuilding it just for the one line change.
Any thoughts on "The Debian Way" (TM) for small repairs or customizations (i.e. outside of /etc/)?
Best regards,
Stephen Benoit.
apt-get source foo cd foo-1.0 patch -p0 < ... debchange -i --nmu sudo apt-get build-dep foo dpkg-buildpackageAnd then distributing the resulting package to the other machines? You will only need to install the build dependencies on your development machine. Also see this article.
[ Parent | Reply to this comment ]
Agreed: this has been my default method.
Now that I am satisfied that my one-line modification was correct, I will file a bug report on the package with a patch. So, to be thorough when reporting the bug, I would rebuild the package with the correction and increment the patch level (from 2.5.1p1-2.1 to 2.5.1p1-2.1custom1). When the official package maintainer releases a bug fix the newer version will replace my customized version.
Thanks for your input!
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
This would certainly be the easiest way to accomplish the job.
Back when I was running Debian Potato I would use dpkg-repack to put together binary packages of proprietary (company) software. But I guess I lost the habit when I started using dpkg-deb and a source tree.
I will keep the dpkg-repack option open.
Thanks for your reply!
[ Parent | Reply to this comment ]
Maybe try to use dpkg-divert feature to create "diverting" package, which will depend on amanda-server and will provide patch-applied version of file?
Regards,
Luke
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
You hit the nail on the head!
I was just replying to bdf about bug reporting when I received your comment, and I agree. reportbug is in my plans for today.
I suspect that this would be a low-priority patch: the amoverview script in question summarizes amanda backup tapes and does not do any heavy lifting functions.
Thanks for the recommendation!
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I think you've gotten the obvious reply "rebuild the package; and distribute it locally" enough times now.
That should be straightforward enough unless you're having to install the package upon >10 machines. For that case you should look at having your own local repository using reprepro, or similar.
If you have >20 machines it might make more sense to install cfengine to manage your hosts. (Or the newer alternative puppet).
Using CFengine I can install patched scripts on 150-200 machines in just a few minutes which is ideal for small changes. (Something I prefer to avoid, but with a management system like that in place these kind of jobs become trivial.)
[ Parent | Reply to this comment ]
I think the best is to report it, if its not general enough it must be, so please help debian being a better distro and report it ;)
[ Parent | Reply to this comment ]
Just as a follow up to "bug" part of the discussion, I used bugreport and it has been filed as bug 447982.
As a general rule, when I need to customize a non-conffile I rebuild the package and set the version to include my initials on the patchlevel (to tell it apart from the maintainer's version).
Thank you for your comments!
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View yvesjmt's Scratchpad ]
Also, take a look at apt-src:
apt-cache show apt-src
Package: apt-src
Priority: optional
Section: universe/admin
Installed-Size: 144
Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
Original-Maintainer: Laszlo Boszormenyi (GCS) <gcs@lsc.hu>
Architecture: all
Version: 0.25.1-0.1
Depends: libapt-pkg-perl (>= 0.1.6), dpkg-dev, apt, perl (>= 5.6.0-16)
Recommends: sudo, fakeroot, build-essential
Filename: pool/universe/a/apt-src/apt-src_0.25.1-0.1_all.deb
Size: 36382
MD5sum: 33182a26cc0be169bda0f96570d1f41e
SHA1: 04425b4cd80046c93b15d4b5210e57550f90e1e0
SHA256: b6d2cb1093673b8f56a76b4d11ecd4b579f38e97152dc668cb64361fbb0c67e2
Description: manage Debian source packages
apt-src is a command line interface for downloading, installing, upgrading,
and tracking Debian source packages. It makes source package management
feel a lot like using apt to manage binary packages, and is being used as
a testbed to work on adding source dependencies to Debian.
.
It can be run as a normal user, or as root. If you want a convenient way to
track updates to packages while preserving your local modifications, this is
a way to do that.
Bugs: mailto:ubuntu-users@lists.ubuntu.com
Origin: Ubuntu
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
If you built the package already once, for testing purposes you can make a quick rebuild using
fakeroot debian/rules binary
as documented in section 6.2 in the Debian New Maintainers’ Guide.
[ Parent | Reply to this comment ]