Re: debtags support proposed for xcontrol
-----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-----
Reply to: