Re: debtags support proposed for xcontrol
On Tue, 8 Apr 2008, Jonas Smedegaard wrote:
Not only do the above mention _re_packaging, the very topic concerns
._orig_.tar.gz. So clearly it concerns non-native packages only.
Well, if you call the single reference to _re_ as a clearly concern
I have to accept this. I never felt that I have to regard it as that
strict. Perhaps Developers Reference should be made more verbose about
this to make it brain dead clear. I was not aware that it might be a
contradiction to what I'm doing.
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.
... which is exactly what I had in mind: Extending the use of the
get-orig-source target. I could have called it get-native-source
as well - I don't mind about the name. It should just work.
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
I completely agree to all points.
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.
Well, this is quite simple to change. If it helps understanding
things I have no problem.
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".
This would be equal to autotools: You have always to call "configure"
before "make dist" because there exists no Makefile before.
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").
This does inspire me to an unrelated thought: Perhaps we should always
use UNRELEASED inside debian/changelog and ask the user to say:
make dist <dist>
where <dist> might be "unstable", "terra" or whatever. So we also
"autogenerate" the debian/changelog to make sure the user is explicitely
aware to build the soure vor a certain target distribution. What do you
think about this?
(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 does not harm if you force me to better explain things. ;-))
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)
If you _really_ want to separate upstream and distro (which I don't
because it is plain nitpicking) it is rather like this in our case:
/ 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)
I see no other chance to respect Debian policy than to configure
(= build a valid fixed debian/control file) as "upstream". But in
my eyes those who build the debian/control file are not upstream
but Debian and that's why the whole concept of upstream and distro
becomes blured and this is by design because the whole point just is
to generate a debian/control file.
It is IMO bad when upstream developers distribute their code without
Makefile.in creates already.
I perfectly agree and that's why we even provide much more. There
is nothing left for auto generation when you build the package because
everything is ready and can be done offline.
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.
Ahhh, I would be astonished if you would agree that easy. ;-)
But your arguments are just not valid to me and I would like to
see a reference design that follows your upstream / distro
separation. The whole point is about generating a valid debina/control
file when being offline. Just tell me how this can be done in
a policy compliant way by separating upstream and distro.
When I develop code targetted specifically for Debian (as was the case
with lessdisks[1]), I keep code and packaging striclty separate:
IMHO this example just does not fit. Meta packages are packages with
no content. So upstream code is just empty.
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.
I don't think that this is the case. IMHO the build system is safe
regarding backporting or rather the whole staff was invented to be
safe about backporting because the control file will be adapted to
the packages that exist in the older distribution.
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.
And I continue to fail to see _why_ you regard it half baked. It
is rather the contray (well done or even over done if such term exists).
Continuing the autotools analogy, I find that your tarballs lack
Makefile.in files:
BTW, have you ever looked into the tarball that is created by "make dist"?
I consider packaging development finalized, when it contains a static
debian/control, and can be built using the following command:
debuild
But it does!!!!
Exactly this was ma change to the non policy compliant formerly build system.
If it would not do so there would be no chance to comlpy to policy. You
obviosely never inspected the released tarball.
I believe that you consider packaging development finalized when it can
be built using this:
make -f debian/rules get-orig-source && debuild
No. Exactly this would fail. This is what I explained Frederic in
Merida. debuild will fail here because the debian dir does not contain
a control file. This control file is only inside the tarball that
was created and which has to be unpacked in some other place. There
you can run debuild (and this is described in the docs). I don't
say that unpacking the source at another place is very convinient
but it is the only means I know to avoid everything that you are
critizising above.
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.
Your considerations are based on guessing.
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.
This is not true. The build system was not broken at all. Holger
_thought_ it would be broken but it was perfectly fine. What was
broken was _another_ _external_ tool that was not able to cope with
a feature that Holger introduced into the changelog. If you would
have tried to build the tarball using "make dist" this would have
been failed which is perfectly correct behaviour because if there
is no target distribution specified no tarball should / can be
released, because no dependencies can be resolved for the distribution
"UNRELEASED". So _if_ you are able to create a tarball for any
specified dist, than this tarball will be perfectly able to be builded
with debuild. If there is no such distribution you will not even get
a source tarball. I would regard this as perfectly reasonable behavour.
As an alternative see my
make dist <dist>
idea.
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...
Well, _I_ believe that you both, Holger and you, assumed that cdd-dev
works differently than it really does. So please make sure that you
at least compare the SVN content with a resulting source tarball
before we continue discussing. This probably would enhance the
discussion drastically.
Because I want to keep source and packaging separate.
If you really want it, please explain how. IMHO this is not
possible here because the source is about packaging. Honestly
I think we could even strip of the tasks files from the source
tarball because they are not needed any more once the control
file is released. I just would like to keep them for later refernce
inside the source package, but debuild would work perfectly
without them (and it has to because the debian/control file has
to be ready once debuild is strated).
I want my final source package to be easy to repackage by others.
In this case you surely need the tasks files (and that's why they
are inside).
A backport should be just changes to to packaging, not to the apckage
Backporting means in this case: Just add a new changelog entry containing
a new version number and the target distribution and than say
make dist
which creates a source tarball for the backported distribution which
that way gets the right information for the debian/control file.
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.
Well, I can see the point that this might be a reason to adopt
the concept of native package. BTW, I do not really like the
version numbers of the debian-edu package with 0.??? anyway.
So you would like to let "make dist" create a
debian-edu_1.x.orig.tar.gz
and use a changelog entry like
debian-edu (1.x-1) unstable
if Debian is the target distribution and
debian-edu (1.x-1terra) terra
for instance if it is targetted to terra?
If you agree with this I tend to my suggestion above which would work out
like this but leads to severe Problems:
1. The SVN contains a changelog which first entry is:
CDDNAME (<version>) UNSTABLE; urgency=low
2. make dist <dist>
--> If dist == unstable the the resulting changelog entry becomes
CDDNAME (<version>-1) unstable; urgency=low
otherwise it becomes
CDDNAME (<version>-1<dist>) <dist>; urgency=low
3. We probably need a means to define under which circumstances the
debian packaging version should be increased and how this should
be specified.
4. The resulting tarball will be called orig.tar.gz
Problems:
1. Interestingly enough the diff.gz file that is created by debuild
will contain nothing because of the special nature of the meta
package thingy
2. Every other debian packaging version than "-1" should provide a
diff.gz against the original tarball. I have no idea how to
implement this because THIS way to backport would bring you
a real lot of problems to solve. It definitely needs a lot of
enhancements to cdd-dev and I personally am not willing to
do this work because of some nitpicking about native and upstream
packages. For sure I adopt patches that solve this problem.
As maintainer I might want to auto-update debian/control, or do other
If you want to update debian/control you can do this via "make dist"
and the result will be a new source tarball.
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.
The method above is the only one I know that complies to Debian
Policy. If you know a better one - just tell me (preferable via
patches ;-)).
To aproach what benefit???
( s/aproach/achieve/ I guess )
You gessed right. ;-)
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.
Well, for this purpose I invented "make dist" to solve all this problems.
The other approach would lead to more problems (see above). Feel free to
solve them. :)
I completely miss your point and the problem you want to solve.
Arrrrgh... :-(
Hope this one was better. :-\
Well, at least in so far that I now understand that you are basically
criticising things I would criticise as well - but which are just not
done. So I would see a general agreement in both opinions. I also
agree that regarding backports / other distributions some orig.tar.gz
approach might be more precise. Here we have to decide between a
precise naming convention which is really hard to implement and the
current implementation which was *designed* *to* *work* with other
dists (like the SkoleLinux dists) and just works.
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.
This final OK seems like my interpretation inside the my last
paragraph was basically right.
Uhm, damn long mail, but hopefully clarifies things.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: