Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Debian contemplates patch management

Posted May 20, 2008 16:57 UTC (Tue) by mbanck (subscriber, #9035)
Parent article: Debian contemplates patch management

That Debian patches are all mashed up together is not true in general.  A lot of source
packages keep their patches nicely seperated under debian/patches and use one of the available
patch systems to apply/unapply them at build time etc.  This has been sort of recommended
behaviour for several years now.

The discussed problem is mostly with source packages maintained in a distributed version
control system, where it is unfeasable to break up the involved feature branches into mere
patches, so they are shipped as one big patch mashed together.  this is suboptimal for people
looking at the .diff.gz, but on the other hand, the source package control file should also
include information on where to find the revision control repository.  There is, however, no
central RCS for Debian source packages.

(Log in to post comments)

Posted May 20, 2008 17:47 UTC (Tue) by phedders (subscriber, #14685) [Link]

"There is, however, no central RCS for Debian source packages."

Apart from Alioth? (Which supports git,svn and hg at least... :O)

No central VCS for Debian source packages

Posted May 20, 2008 23:20 UTC (Tue) by bignose (subscriber, #40) [Link]

> Apart from Alioth? (Which supports git,svn and hg at least... :O)

First, "supports Subversion, git, Mercurial, Bazaar, etc." is not "central VCS", it's several
disparate VCSes. If Alioth supported only one VCS, it might qualify; but such a choice would
not be popular with those users whose VCS was not the one chosen :-)

Second, Alioth is not for *all* Debian packages, but only those free-software packages that
require collaborative maintenance. The Alioth admins reject requests to use it merely as
storage for a package without a need for ongoing collaborative maintenance.

No central VCS for Debian source packages

Posted May 21, 2008 7:59 UTC (Wed) by pkern (subscriber, #32883) [Link]

> The Alioth admins reject requests to use it merely as storage for a package without a need
for ongoing collaborative maintenance.

Well, things can be kept in ~/public_{hg,git,whatever} and people are also free to use the
collab-maint repositories, which are often used as simple storage of a package's history.

No central VCS for Debian source packages

Posted May 22, 2008 6:16 UTC (Thu) by rhertzog (subscriber, #4671) [Link]

>The Alioth admins reject requests to use it merely as storage for a package without a need
for ongoing collaborative maintenance.

This is wrong. See http://wiki.debian.org/Alioth/PackagingProject for details. You can host
your VCS repository in collab-maint even if you're alone working on your package.

Alioth is clearly the most used resource to host VCS for package management but it's not a
resource that has to be used by everybody. Each maintainer has the liberty to host it
whereever he prefers.

-- Raphael Hertzog, Alioth admin

No central VCS for Debian source packages

Posted May 22, 2008 19:16 UTC (Thu) by bignose (subscriber, #40) [Link]

My understanding of Alioth's policy was based on a rejection notice I received a while ago:

> looking at the description of your project request, it's not clear at all that you need a
full Alioth project to effectively co-maintain your package.

(This rejection was quite justified, IMO.)

From this I understood that Alioth doesn't accept "it's a Debian package" as the sole basis
for hosting a package. It was this that I referred to in my initial comment on the article.

I suppose that, although the above rejection notice doesn't mention Alioth's 'collab-maint'
project, it doesn't exclude the possibility either.

No central VCS for Debian source packages

Posted May 22, 2008 21:58 UTC (Thu) by rhertzog (subscriber, #4671) [Link]

>My understanding of Alioth's policy was based on a rejection notice I received a while ago:

The subject of that rejection is "Please use collab-maint" and the second paragraph says:
"Please check out http://lists.debian.org/debian-devel-announce/2006/04/msg... and
http://wiki.debian.org/AliothPackagingProject"

It's that not enough hints to point you to collab-maint, I don't know what we can do. :-)

-- Raphael Hertzog

Debian contemplates patch management

Posted May 20, 2008 17:53 UTC (Tue) by sbdep (subscriber, #13282) [Link]

>Some Debian packages are built this way already, though the practice is far from universal.


As mentioned in the article, yes this is in place in Debian, where the diff.gz carries all the
patches that extract into the debian/patches directory and are applied at build time.

The problem with this approach is that there are half a dozen different "standard" ways to do
this plus probably a few homebrew solutions and they all operate differently.  My opinion is
that if this method of managing patches is to be really endorsed by the Debian Project, then
one mechanism needs to be mandated in policy and used project wide.


Overall, many of the "core" packages do tend to use a patch system of some sort, but of the
thousands of Debian packages, most do not and ship just a diff.gz that applies directly to the
source code.  Of course, most debian packages are also relatively small pieces of software and
probably do not need a full patch management system since the patches are mostly build system
fixups and small minor changes.

Debian contemplates patch management

Posted May 21, 2008 0:03 UTC (Wed) by dbnichol (subscriber, #39622) [Link]

"That Debian patches are all mashed up together is not true in general."

Even if the patches are separated, they are _distributed_ mashed together with a bunch of
other files in a compressed diff. That raises the barrier to finding out what's in a Debian
package. Compare that to figuring out what's happening in a RH/Fedora package:

http://cvs.fedoraproject.org/viewcvs/devel/sed/

FWIW, I think patches.ubuntu.com is a vast improvement over a diff.gz, even with the nearly
nonexistent metadata.

Debian contemplates patch management

Posted May 21, 2008 9:28 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

Are all Fedora packages maintained in a central CVS?

The equivalent for openssl:

http://packages.qa.debian.org/findutils

You get a link to a repository and to a browser. In the browser:
http://svn.debian.org/wsvn/pkg-findutils/trunk/ 

No go to debian/patches .

Not all packages are team-maintained, and thus finding this is a bit more difficult.

Debian contemplates patch management

Posted May 21, 2008 10:46 UTC (Wed) by cyperpunks (subscriber, #39406) [Link]

> Are all Fedora packages maintained in a central CVS?

Yes, that's the only way to include packages in the distro, as *all* packages are built in
koji ( http://koji.fedoraproject.org/koji/ ) from the sources in cvs.

Debian contemplates patch management

Posted May 21, 2008 16:09 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

/me points to http://packages.qa.debian.org/findutils again
(it actually redirects to http://packages.qa.debian.org/f/findutils.html )

Here you can find all the information about the package. Including logs from the build
servers.

A package is rebuilt on build servers after it has been submitted by its maintainer. The
maintainer may maintain it in a version control system or may  write each and every new
version using butterflies. But once the maintainer uploads the candidate version to Debian, it
gets into the archive. This does not take a centralized VCS.

The package in that example is maintained in a separate subversion repository. It would still
be possible to use that even after other maintainers start using better methods such as
svn2.0, git, bzr and super-duper-future-vcs.

In fact, isn't the input to koji a source RPM?

You are still looking on this from Debian developer's viewpoint

Posted May 21, 2008 17:26 UTC (Wed) by khim (subscriber, #9252) [Link]

Here you can find all the information about the package. Including logs from the build servers.

I don't need logs from build servers. I don't need links to "svn2.0, git, bzr and super-duper-future-vcs". What I (mainstream developer) need is simple way to see what patches were applied to the source. Fedora's CVS makes it trivial. Debian's control center is much harder - it's as simple as that. Case to the point: after all this hoopla with openssl how can I get list of patches in this important package? With Fedora - it's trivil: find your package in big list, click on it's name and get the list of all patches. You'll probably want to do two additional clicks to see when patches are actually applied in build process, but it's always the same scheme, it's always simple and easy. Debian's approach is flexible, powerful and... error-prone. Each package can have it's own VCS, it's own patch management system, etc - not so easy to just find the list of chnages.

Debian contemplates patch management

Posted May 21, 2008 18:15 UTC (Wed) by cyperpunks (subscriber, #39406) [Link]

> In fact, isn't the input to koji a source RPM?

It can be, however not in this case. 
Package is built from spec file and sources in cvs. 
koji builds the source and binary RPM.

Debian contemplates patch management

Posted May 21, 2008 2:10 UTC (Wed) by yarikoptic (subscriber, #36795) [Link]

>  There is, however, no central RCS for Debian source packages.
Indeed there is none of central one, but most of the packages now carry Vcs-{git,svn,...} and
Vcs-browser fields in their debian/control files. and very many keep their central VCS (or
some kind of clone) on alioth (although it is irrelevant indeed), especially if maintenance is
collaborative (ie by a team).

AND there is a tool now withing Debian's devscripts: "debcheckout -  checkout the development
repository of a Debian package" which makes use of those Vcs fields, so if I need a possibly
updated maintainer version of repository for fail2ban I just run 'debcheckout fail2ban' and I
see everything -- upstream, debian sources and branches which were merged into the release
branch, quite easy and quick. Sure thing not all packages provide Vcs- header fields but quite
a few

Debian contemplates patch management

Posted May 22, 2008 19:53 UTC (Thu) by oak (subscriber, #2786) [Link]

> That Debian patches are all mashed up together is not true in general.

So, what would be needed nowadays to get *reliably* all the patches that 
are being applied to Debian base packages, say for the ARM architecture?

At least few years ago that was about impossible task, only way to get 
automatically correct patches (applied), was building the Debian packages 
(which requires doing this in an environment supporting that) and because 
Debian packages do not support cross-building like some other 
distributions...

No patch serties out of DVCS?

Posted May 23, 2008 1:56 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

Sorry, but all distributed version control systems (DVCS) I know allow you to extract a clean patch series more or less painlessly. If the user doesn't do so, well, you know who is to blame...

No patch serties out of DVCS?

Posted May 23, 2008 13:27 UTC (Fri) by mbanck (subscriber, #9035) [Link]

Sorry, but all distributed version control systems (DVCS) I know allow you to extract a clean patch series more or less painlessly.

One of the popular workflows seems to be keeping seperate patches in different (mutually conflicting) feature branches and then resolving those conflicts in an integration branch, which leads to a source package. I don't know whether dropping a working and useful patch series is feasable somewhere in the workflow, as I do not use DVCSs to maintain my packages myself.

Michael