-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Apr 07, 2008 at 08:28:10PM +0200, Andreas Tille wrote: > On Mon, 7 Apr 2008, Jonas Smedegaard wrote: >> Updating stuff below the debian dir in the get-orig-source target >> seems wrong to me: I would expect that target to only deal with, >> well, getting the original source as a compressed tarball. > > I can not parse this sentence (do not understand whether you agree or > disagree with the get-orig-source approach) and what are your reasons.
>> Do you use get-orig-source in some automated routines? Then I would >> be interested in understanding those too - for the same reason. > > No, I don't if you don't call the "make dist" as described in [1] > which simply masks the "make -f debian/rules get-orig-source" as > "automated". > [1] http://people.debian.org/~tille/cdd/ap-QuickIntro.en.html I disagree with the get-orig.source approach. To me, get-orig-source is a pseudo-standard for pulling upstream source in a VCS workflow of packaging non-native software: 1) Checkout/clone packaging from VCS 2) Pull upstream source 3) Prepare build 4) Build package I see it as comparable to core software routines: 1) Setup build environment 2) Get source 3) configure 4) make + make install You seem to use get-orig-source in Debian-native packaging to _generate_ the source package: 1) Checkout/clone source+packaging from VCS 2) (re)generate parts of packaging 3) Build package I dislike that approach. I see it as comparable to those upstreams including dependent libraries into their tarball, and not caring to clean source properly or finalizing autotools files: 1) Setup build environment + half-baked source 2) autoreconf + configure 3) make + make install The line between content and framing, source and packaging, is blurred. In my opinion get-orig-source should *only* provide your with what should be the "master" for packaging: the compressed tarball uploaded as-is to Debian. It should IMO *not* also change your working environment. In other words: it should be used to "get original source" (not to "finalise original source"). Here is a more complex packaging example with both dfsg-repackaging and policy-violating control file editing: 1) Checkout/clone packaging from VCS 2) Pull upstream source a) pull upstream pristine source b) unpack pristine source c) strip DFSG-violating parts d) repackage 3) Prepare build a) regenerate control file b) commit changed control file to VCS (or don't...) 4) Build package c) build (inside a clean chroot using cowbuild) A non-maintainer would follow same steps, but would in 3) only add a changelog entry (+ whatever custom hacks they would want themselves). For a package created from scratch for a CDD I would still use above separation: I would develop and release the software parts outside of the Debian dir in a separate VCS (or a separate Git branch). I generally dislike Debian-native packaging, exactly because they do not handle source and packaging separately: If NMU'ing, backporting or doing other non-maintainer work, you cannot just replace the diff (to easily track your changes using interdiff) - because there was no diff to begin with, only source and packaging mixed together in an "upstream" tarball. Hope that was easier to understand... - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH+q9Kn7DbMsAkQLgRAlmEAJ9ZmdP1/fh5mAqwrws1XlVFcqammQCghPhS V9iyY6lWRg+ivSB0QY9+iiM= =m2Hw -----END PGP SIGNATURE-----
