On Thursday, May 17, 2012 10:52:02, Gergely Nagy wrote: > Chris Knadle <Chris.Knadle@coredump.us> writes: > > On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote: > >> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: > >> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: > >> > > No, I hereby start saying good by to 3.0 > >> > > >> > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have > >> > also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 > >> > for my last few packages. > >> > >> I can't see any reason to use 1.0 anymore, ever. > >> > >> It is true that 3.0 (quilt) does have a great downside, quilt, but it > >> also has a number of upsides. And working around quilt is simple: > >> > >> echo "single-debian-patch" >debian/source/options > >> echo "/.pc" >>.gitignore > >> echo "/debian/patches" >>.gitignore > > > > 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? > > Git does have a complete view. What the above does, is tell dpkg-source > to fold any changes made to the upstream sources into a single > patch. Since the git tree already has the patches applied (with upstream > sources on a different branch, most probably), it has a full view. > > This basically folds whatever patches the git tree has over upstream, > outside of debian/ into a single file. That's about it. Since that file > is generated, it has no business staying in git. So essentially this uses Git to create the 3.0 (quilt) format without actually using quilt, yet acts similar to the original 1.0 format of making a single patch. That's pretty interesting. Thanks for the explanation. > >> Except for nuking upstream debian/ dir which can mean a bit of lost work > >> if the upstream is sane (and can save some if they're not), the 3.0 > >> format is strictly better than 1.0. > > > > If debian/ is nuked then so is debian/patches, and if Git has been told > > to ignore debian/patches then it cannot bring those files back. > > You're misreading this. "Nuking upstream debian/" means ignoring any > debian/ directory upstream may have had. That is generally a Good > Thing(tm), as we want to have our own packaging. Okay. I don't commonly see debian/ directories in the upstream sources themselves, so I couldn't tell that's what you had meant. > The original is still available in both the upstream tarball, and the > upstream branch. debian/patches in this case is irrelevant, as that is > automatically generated by diffing the upstream tree against the current > (git) tree and folding it into a single patch file. Yes I see. > > Patching the source can be an effort especially concerning documenting > > why the patches were done and the source of the patches, so these seem > > like they'd be important to track rather than something to ignore. > > The reasons can - and should be - documented in git. Granted, that does > not transfer to the debianized source package, which is unfortunate, but > it's still better than fighting with integrating quilt with a VCS (in > which case, everyone with a higher number of patches would go back to > 1.0 and custom patching systems and ignore every other benefit of 3.0, > because quilt and VCS generally don't play nice together). One of the problems I'm running into is in working on updating a package that has been abandoned and is now three years older than upstream, and which has a single (1.0 format) patch with no notes in the files themselves, and no VCS location. I can look through the changelog in the package, but without any way of matching up dates due to the patch being bundled into a single file, I cannot seem to match up what changes within the patch match up with the changelog, so I cannot tell which elements of the patch may still be relevent today with a new upstream version of the software. If Git had been used it would be possible to figure out which commit made what change, but it would still be a lenthy process. Quilt patches with annotated headers to describe each patch still seems like they have an advantage in that the annotated headers are in the patch files themselves. I'm not sure which is better at this point (and it may depend on the situation) but either way it's nice to know about both options. Thanks. -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Attachment:
signature.asc
Description: This is a digitally signed message part.