Re: debtags support proposed for xcontrol
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Apr 08, 2008 at 08:55:24AM +0200, Andreas Tille wrote:
> 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? ;-))
Ah - thanks for pointing to the definition below - that was exactly what
I did not know existed. So forget about my personal attempt at defining
- - I instantly adopt the one below!
>> 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.
Not only do the above mention _re_packaging, the very topic concerns
._orig_.tar.gz. So clearly it concerns non-native packages only.
But it defines a _process_ and use of a generic name. You are welcome
to use same name for other purposes - like a comparable process for
native packages.
I just don't recognize your process for native packages as comparable,
and is concerned about the confusion it can cause:
* You don't "get" the source. The native package _is_ the source
* The "orig" source is what you had _before_ running the target
* the result is not "source" but autogenerated files
So get-orig-source really make-dist-config a I see it.
Really I would recommend to just use the classic "dist" target that it
wraps around anyway.
>> 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?
No problem here. I just describe non-native packaging that I find sane.
I mention it to compare with the below which I dislike:
>> 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.
Right.
>> 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.
Sorry for my bad description. I agree with your description. Only it
seems to me that your current design requires a "make dist" after a
"configure". That you do not "finalize", and after that allow treating
the package as any other package (like being able to run "debuild" even
if distro field is "UNRELEASED").
(It might simply be that I misunderstand details of cdd-dev, and we
completely agree on all these matters. That I am just so very bad at
explaining myself.)
It is sane as upstream to use autotools, but only if finishing before
passing on the code to distributors:
This I find sane:
/ write code
upstream < setup build hints (Makefile.am + configure.ac)
\ generate build system (autoreconf)
/ configure (add changelog entry)
distro < use build system (make + make install)
\ package (debhelper + friends)
This, however, I dislike:
/ write code
upstream \ setup build hints (Makefile.am + configure.ac)
/ generate build system (autoreconf)
/ configure (add changelog entry)
distro < use build system (make + make install)
\ package (debhelper + friends)
It is IMO bad when upstream developers distribute their code without
Makefile.in creates already. To upstream those files are temporary, but
to distributors those files are part of the source.
Sure, it is all free software, and distributors _can_ regenerate
automade files similar to upstream, but it is discouraged in Debian,
because really the process of autogenerating the build system is most
sanely treated as part of upstream development, not downstream
redistribution.
You might then argue that designing a CDD is all packaging, no upstream.
And you are free to see it that way - I just disagree.
When I develop code targetted specifically for Debian (as was the case
with lessdisks[1]), I keep code and packaging striclty separate: With my
"upstream" hat on I develop some code and "release" a tarball containing
no debian/ subdir (but possibly a proposal dist/debian/ one), then I
switch to my "distro" hat, apply a debian/ subdir (possibly based on an
upstream supplied distro/debian), and build packages from that.
Similarly, when I do "magic tricks" to debian/control, I separate my
_pakaging_ routines themselves in "devel" and "distro" parts. It must
be possible to repackage my package without knowledge of the magic part.
With my "upstream" hat on, all files may be dynamically generated from
outside sources or relying on the phase of the moon. But whatever I do,
I must freeze it, so that my potent tricks does not explode in the hands
of some backporter or build daemon later on.
Main point is that I "finalize" the "upstream" part, even though I do
both myself. The separation allows others to repeat the packaging the
classic way, without needing to know about the internals.
>> 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.
Sorry - I did not mean to say that your "released" code was unclean. I
mentioned 2 classic types of badly released upstream code - unclean and
half-baked. I only find that your code is half-baked.
Continuing the autotools analogy, I find that your tarballs lack
Makefile.in files:
With autotools, code that is finalized contains Makefile.in, and can be
built using "configure && make && make install".
I consider packaging development finalized, when it contains a static
debian/control, and can be built using the following command:
debuild
I believe that you consider packaging development finalized when it can
be built using this:
make -f debian/rules get-orig-source && debuild
I consider the get-orig-source build target as comparable to the
relibtoolize command. Or the autogen.sh script commonly included in VCS
development trees, but often stripped from the finalized tarball.
In the development of the debian-edu CDD, José joined the upstream part
and worked on composing task files. Recently the build routines broke
due to wrong "configuration" (package was built with distro field in
changelog still the bogus UNRELEASED) and Holger wondered how cdd-dev
was really supposed to work.
I believe that Holgers confusion had to do with assuming that the
package could be treated as just a package. But no, your package is a
_native_ package that is only finalized _after_ being passed on to the
packaging crew...
>> 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?
Because I want to keep source and packaging separate.
I want my final source package to be easy to repackage by others. A
backport should be just changes to to packaging, not to the apckage
itself (unless of course the package needs patching to work in the alien
environment, but that's another story). With native packages there is
only a single version number, and a single tarball, so you cannot avoid
messing with the "source" of the package, and must either introduce a
new packaging version, or bogusly bump upstream version number.
>> 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.
As maintainer I might want to auto-update debian/control, or do other
stuff that is "surprising" to classic dpkg build routines. I want
smarter build routines, but also *must* offer classic routines to not
violate Debian Policy.
>> 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???
( s/aproach/achieve/ I guess )
Separation of packaging routines, not for my own use, but for the use of
others - build daemons and developers wanting to NMU/backport/whatever
but is uninterested in the fancy tricks I use myself.
>> 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.
Arrrrgh... :-(
Hope this one was better. :-\
> 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).
Ok.
- Jonas
[1] In principle, Vagrant was upstream for lessdisks and I just packaged
it. But lessdisks was - similar to complex CDD development - closely
tied to the packaging, so I ended up hacking directly in "upstream"
code, only some of it coordinated properly with Vagrant, causing massive
headaches for both of us later on. But that's another story...
- --
* 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+7ywn7DbMsAkQLgRAg+vAJ49/Y0GBk031H64ysCmut4NEy3kPACgk0Wa
u56uIzxEfPIm/4H7u21/FqQ=
=IHQb
-----END PGP SIGNATURE-----
Reply to: