Re: debtags support proposed for xcontrol
On Tue, 8 Apr 2008, Jonas Smedegaard wrote:
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:
Well, do we have another case for a "to me"-definition? ;-))
From developers-reference:
---------------------------------------------------------------------
6.7.8.2. Repackaged upstream source
...
A repackaged .orig.tar.gz
1. must contain detailed information how the repackaged source
was obtained, and how this can be reproduced in the debian/
copyright. It is also a good idea to provide a
get-orig-source target in your debian/rules file that
repeats the process, as described in the Policy Manual, Main
building script: debian/rules.
---------------------------------------------------------------------
So the only weak point in this approach is whether a native package
can be _re_packaged. But I see no real need to stress this "re-"
very much.
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
In principle yes - but where is the problem?
You seem to use get-orig-source in Debian-native packaging to _generate_
the source package:
Well - at least the part of the source package which is auto generated.
1) Checkout/clone source+packaging from VCS
2) (re)generate parts of packaging
3) Build package
Yes, this is right.
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:
Ups, this is a really strange comparison! It is rather like upstream
that keep manually editet files like Makefile.am and configure.in in
their VCS and creating auto generated stuff like Makefile.in and
configure via autoconf; ...; make dist. To stress this analogy we
also provide a "make dist" target in case the CDD uses the suggested
Makefile which just simplifies things.
1) Setup build environment + half-baked source
2) autoreconf + configure
3) make + make install
STep 3) is just wrong. We stop between 2) and 3) and the analogy
is "make dist". I completely fail to see why you think that we
forget to slean source properly. The make clean target does not
include configure / Makefile.in neither does even make distclean.
The line between content and framing, source and packaging,
is blurred.
I completely disagree.
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").
So you just care about the _name_ of the beast "get-orig-source" and
would rather like something as "prepare-compressed-native-tarball" as
the target name? To be honest: I don't mind about the name if this
disturbes anybody. Feel free to change it in source AND docs ...
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...)
I fail to see a reason why in this process the control file should
be changed? Why not putting the correct control file into VCS and
combine this with changed or unchanged upstream source?
A non-maintainer would follow same steps, but would in 3) only add a
changelog entry (+ whatever custom hacks they would want themselves).
I fail to see the reason why a non-maintainer should follow these
steps and where you see the difference between building a package
as maintainer and as non-maintainer.
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).
To aproach what benefit???
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.
Well, this sounds strange because the main part of what you call
non-native is just stuff to actually build the debian packaging.
So this aproach would be absolutely senseless in my eyes. Perhaps
I completely fail to see your point, but IMHO you want to add an
extra level of complexity for no benefit at all.
Hope that was easier to understand...
No it was much more confusing than any other mail from you. Sorry
I completely miss your point and the problem you want to solve.
We found means to create a source tarball which enables us to build
Debian packages in a policy compliant way. So in my eyes splitting
this up to stick to the narrow meaning of "get-orig-source" is
extra owrk for no profit at all and I personally refuse to change a
running system but I'd consider working patches (to code _and_ doc).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: