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

Re: Proposed patch management/build solution



On Mon, Jan 21, 2002 at 12:15:46PM -0500, Sam Hartman wrote:
> 
> 
> As I mentioned Saturday, I'm interested in helping set up some sort of
> system for managing patches that we are not comfortable sending back
> to Debian packages yet.
> 
> I'm concerned that without such a system:
> 
> * Different people will each set up their own archives of packages
>   with different mechanisms for  marking local changes

A valid concern, albeit not one I have at the moment; I only build 'clean'
upstream sources at this point, mostly to avoid problems with this.

> * Some of these archives may not include source packages and thus may
>   violate the GPL or other licenses

dpkg-buildpackage -sa, debarchiver. Feel free to look at the results in
my archive.

> *   It will not be easy or possible for a random person to rebuild the
>     entire system, which could be critical for debugging

I'll worry about this when it doesn't require a chroot tarball just to
get things up and running. Until then... the only folks who're likely
to be even remotely interested in debugging are the diehards, who can
find all they need in the list archives.

> *  We may not easily be able to pull in new versions as Debian
>    packages evolve, or we may accidentally lose changes we want to
>    keep

Another good concern. cvs-buildpackage, which you propose below, is
the correct answer.

> I have a proposal for how I plan to do things.  My design goals are as
> followss:
> 
> * Facilitate development by a group of people not just individuals
>
> * Slightly more centralization than the standard Debian archive; the
>   standard Debian archive has several conditions that make its
>   decentralization work  that i don't think currently apply to this
>   project.  I can go into detail if people like, but I'd rather do so
>   off list.
> 
> * Single well defined format for describing NetBSD-specific changes
> 
> * Mandate that people describe  their changes and clearly label our
>   versions as modified
> 
> * Set up version control.  What we are doing is clearly active
>   development; it is easy to show that many problems result from not
>   having good version control for active development software
>   projects.
> 
> * Minimize bandwith.  Several of the people involved  seem to have
>   limited Internet connections.  Requiring them to download large
>   chunks of source over the net rather than from convenient local
>   mirrors  would decrease their ability to contribute.

Generally admirable goals, though I have my doubts.

> So, here's what I propose to do.  I want to set up a CVS repository
> with two top level directories.  The first directory will be called
> packages; it will contain  any  BSD-native packages we've developed.
> It will contain their sources in a format compatible with
> cvs-buildpackage.  I know at least one such package will exist.
> 
> The second directory will be called patches and will contain
> directories corresponding to source packages we've had to patch to get
> them to build on BSD.  Each source package directory will contain some
> or all of the following:
> 
> * A file called version that contains the version of the source
>   package these patches are for.
> 
> * A file called patch that will be applied after the dpkg-source -x
> 
> * A file called changelog.add that will be prepended to
>   debian/changelog
> 
> * One or more files called after-foo-patch which will be applied after
>   running debian/rules foo.  The most common example might be
>   after-setup-patch which should help with DBS patches
> 
> I will also write a small native package that contains a script to
> build a source package based on one of these patch directories and a
> program to build all patched packages.

I *strongly* advise you to look at the existing auto-patch system that
is in place.

> Then we can set up this CVS repository somewhere (presumably initially
> sourceforge) and allow people to start committing their patches.  I
> think this organization will really help me be able to debug things
> and make forward progress; will it help others enough to be used?

How will you handle detection of patches appearing upstream? Who has the
authority to remove patches? Will there be an autobuilder working from this
tree, and, if so, where will the packages appear?
-- 
***************************************************************************
Joel Baker                           System Administrator - lightbearer.com
lucifer@lightbearer.com              http://users.lightbearer.com/lucifer/



Reply to: