On Wed, 16 Mar 2011, Neil Williams wrote: > On Tue, 15 Mar 2011 23:35:59 +0000 > Ben Hutchings <b...@decadent.org.uk> wrote: > > On Tue, Mar 15, 2011 at 10:55:54PM +0000, Neil Williams wrote: > > > Other tools, like svn-buildpackage, don't have this problem, via the > > > mergeWithUpstream support and/or a ../tarballs/ directory. Not perfect > > > but it works. > > [...] > > > > mergeUpstream works only if you never want to look at upstream changes. > > Personally, I'll use debdiff on the .dsc to view changes of all types, > prior to further testing / installation / pbuilder / upload etc. The > upstream changes are available and, in some ways, having a > separate ../tarballs/ directory means that I can unpack > both .orig.tar.bz2's and compare the upstream code directly without > needing to think about the effect of Debian changes, if I want to look > at these in isolation. > > Generally though, my problems are confined to a single corner case: > native packages using autotools. > > It's such a minor irritation for this specific package that I haven't > got the need to change the package build system (the package code is > stable), I haven't even got sufficient need to change the VCS. One day > I'll get around to a proper solution but I am curious about whether > others have similar problems with such packages. It probably comes down > to a bad choice of build system, if I'm honest.
Well, I have been doing this, for a LONG time, to preserve my sanity when working as upstream or in a native auto-tooled package: 1. No spawn from autotooling allowed in the VCS. EVER. .gitignore it away at once. Autogenerated files inside the VCS repo are almost always a bad idea. It was madness with CVS, it was bad mojo with SVN, and it is certainly at least an annoyance with git. 2. Add an autogen.sh script that makes it trivial to retool everything as needed. Keep it up-to-date. 3. I always hook the debian package to retool on package build. I have no reason to trust whatever cruft upstream shipped, even if I happen to be upstream at that moment in time. It also means I will instantly notice if upstream started doing very "unpure" things to the build system, such as directly modifying autogenerated files, and it lets me try to contact them (or fix my ways, if I am upstream) and contain the braindamage before it causes any Debian victims. 4. Just deal with the annoyance in the debian clean target, but do use make distclean, as it increases a lot the chances of automated removal of autotool cruft. GNU really never thought of the need for autotooling cleanups, as it does autoretool in place (and left over cruft is simply ignored and doesn't crap the build). 5. Cheerfully ignore any purists complaining that debian/rules clean does not restore whatever crap was there upstream. I have so far, in what must be around 15 years of being a DD (or close to that, anyway), never seen a SINGLE real usecase for that, either as downstream, upstream or an user... so I don't consider it worth the trouble or extra complexity. Note that I will change my position in this if someone with a valid, real usecase ever complains about it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110316193506.gf7...@khazad-dum.debian.net