Re: New Packager question again: can you point me to a not flawed package?
"Paul Johnson" <pauljohn32@gmail.com> writes:
> On Sat, May 31, 2008 at 9:59 PM, Russ Allbery <rra@debian.org> wrote:
>> At this point, I've converted most of my packages to use Git, which
>> means that the source package as uploaded to Debian has one collapsed
>> patch including upstream changes and you have to check out the Git
>> repository to see the separate branches and how they relate to
>> upstream.
> You don't keep a patches subdirectory under debian?
The idea of using a distributed VCS to manage the package is to use its
merge capability rather than a more manual patch update process. To some
extent it's an experiment, since I really do like quilt, but it's working
fairly well so far. Git lets me manage branches the way that I managed
patches and provides a much richer set of commands to manipulate those
branches (although it requires some work to figure out which ones to use
and how).
>> At some point, I'm hoping to be able to generate format 3.0 packages
>> from Git in some way that exposes the way that I'm actually working to
>> other people working on packages.
> I can't understand why you would do it this way. Seems like it would
> lead to hard-to-catch coding mistakes.
Using Git with feature branches for each patch is exactly equivalent to
using separate patches in a debian directory. You can transform one into
the other (although feature branches allow more complex merges). It's the
same work flow, except you work on nodes rather than edges. It's a
classic graph transform.
> If there were 50 patches, some of which others contribute, there might
> be a chance to figure which one blows something up. As long as the
> patches are separate, there's a chance I could back-track and find the
> problem. But it seems like you are saying that you apply those 50
> patches, and then make one jumbo diff including all changes.
Only in the final build of the source package after everything has already
been merged. The working object is 50 separate feature branches, each of
which contain only one change, and which I can merge and update
indepedently. The only difference is when one does the merge and what
artifact of the merge one puts into the source package.
Right now, the Git method is less than ideal for anyone working only on
the source package, since they get the merge artifact without any of the
underlying structure. 3.0 package formats will fix that; in the meantime,
if they have Git, debcheckout will get the actual repository and let them
work on the same thing that I'm working on.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: