Re: New Packager question again: can you point me to a not flawed package?
On Sunday 01 June 2008, Russ Allbery wrote:
> "Paul Johnson" <pauljohn32@gmail.com> writes:
--cut--
> > 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.
True. This is cool and helpful for the DD point of view while working with
their $VCS, but might leave users of diff.gz with one single jumbo diff which
modifies several upstream files. Please note that these users (which might
happen to be the upstream developers of your package) might not even have
your $VCS of choice installed or devscripts package to use debcheckout, they
might be pure $UNIX users relying on patch, diff and a simple text editor.
So, will you generate at some point a series logically separeted quilt
patches and store them in debian/patches/ in the final diff.gz which is the
canonical way of Debian to distibute changes.
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: