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

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

On Thursday, May 17, 2012 10:54:15, Jon Dowland wrote:
> On Thu, May 17, 2012 at 10:41:37AM -0400, Chris Knadle wrote:
> > I'm confused concerning the above; the point of a VCS in this context is
> > to track changes to the source package, and the patches are themselves
> > important changes to the source package.  If you have Git ignore the
> > patches then Git doesn't have a complete view of the source package
> > anymore.  Why would you want to do that?
> It's the other way around. You manage changes to the source package as
> commits in the VCS; perhaps tracked on separate branches, perhaps not. The
> source package ends up being a flattened version of all of these commits. 
> So the 'preferred form for modification' is the VCS archive; the source
> package is a second class citizen.
> So to follow Adam's instructions you would first apply each of the patches
> as a commit in your VCS, then delete them, then ignore debian/patches
> going forward (treating it as an implementation detail of a legacy source
> archive format)
> Yes, I think it's a shame if the preferred form for modification wasn't the
> source package.  I also think it's turning a blind eye to say putting git
> repos in as source packages would be not worth the work to audit them; but
> we can keep hosting them at git.debian.org just fine.

Although I like the /idea/ of being able to modify the source package directly 
via Git as if there were a "3.0 (Git)" source format, I also think it's 
important to be able to verify the source download that came from upstream.  
Including the original source tarball isn't enough because that is then being 
modified.  Doing something like 'git diff <original-source-commit>..HEAD' to 
find out how the source has been changed would presumably also contain diffs 
from debian/ files not related to the source.   Looking at the manpage for 
'git diff' it isn't immediately clear to me how you'd filter those out.  
[Although I'm sure there's a way.]

Another thing I've seen with another package I'm working on in collaboration 
is using a Git repo in which the only contents are the debian/ files and not 
the original source tarball nor source files at all.  To do a built the source 
is then downloaded via uscan, expanded, and the debian/ directory is copied 
into the expanded source directory, and then built.  With this kind of 
configuration no source files are tracked in Git, so instead it's necessary to 
track debian/patches so that patches can be applied to the "pristine" source.

At the moment I'm following the latter methodology to see how well it works 
out and whether I like it.  If anyone else has used this method and has 
comments on it, I'd be interested in reading them.


  -- Chris

Chris Knadle
GPG Key: 4096R/0x1E759A726A9FDD74

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: