Re: debtags support proposed for xcontrol

[Jonas Smedegaard <dr@jones.dk>]

-----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-----