Re: Proposed patch management/build solution
This is a good idea. I'm interested in it.
Why not simply import the standard Debian source packages as vendor branches,
and use the normal CVS facilities to track the changes? This seems simpler than
keeping patches in separate files, as you describe below. Also, it should work
with cvsbuildpackage.
It's worth noting that there are three common kinds of patches:
1. Patches needed to get the package to build or work, because XYZ isn't there
yet. (i.e. Don't build documentation, because there's no SGML tool.)
2. Patches to fix confused makefiles. Some packages don't use configure, (or
don't have some of the tests they need) and have to be tweaked to work in
the Debian BSD environment.
3. Libc differences. Some packages assume glibc, and fail because of that.
These seem to be mostly Debian native packages.
The first kind of patch is temporary, and can go away once things are further
along. The other two kinds need to be sent upstream. The real difficulty is
getting them separated out, and having someone get them merged back into the
sources.
I know that in my case, I was primarily trying to get a minimal base system
working, so that I could get rid of all of the first type of patches (kludges
really), and go on and deal with the real issues.
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
>
> * Some of these archives may not include source packages and thus may
> violate the GPL or other licenses
>
> * It will not be easy or possible for a random person to rebuild the
> entire system, which could be critical for debugging
>
> * 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
>
> 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.
>
> 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.
>
> 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?
>
>
> --
> To UNSUBSCRIBE, email to debian-bsd-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: