Bug#380227: texlive-bin: Why is the source in a tar.bz archive?
Norbert Preining <firstname.lastname@example.org> wrote:
> You didn't get the answer I wrote the last time, what do *you* say to
> this argumentation?
Oh, I guess I did get the answer, but I completely forgot. You wrote:
> Upstream ships source.tar.bz2, my plan was that one can drop the
> ./debian subdirectory of any texlive source package into the TeXlive DVD
> (with unpacked tpms) and run make -f debian/rules binary.
> Maybe a vain hope ...
Well, what would we gain with that? Of course it looks clean and nice.
However, I doubt that many people will actually make use of such a
feature. Either you are just interested in having packages, compiled
for your machine and maybe with some patches, then you can simply do
"apt-get source". Or you're more interested in how the packaging is
done, then you want to look at the Debian-specific repository, anyway.
I think it's rather something else that would make sense: To be able to
drop the "trunk" directory of our svn repository into the TeXlive DVD,
and build stuff from there. Or maybe both possibilities.
With the current setup, I find it hard to work on the sources. I can do
"debian/rules unpack-stamp", after that I can look at the sources,
prepare patches etc. But if I try what the result of a configure run or
a test compile is, I have no easy, Debian way of cleaning without
loosing my work. If the Debian package had the sources unpacked, and
additionally would use the clean (or distclean?) target of upstream's
Makefile, both doing it and finding out how to do it (namely, do I have
to run distclean or clean or what?) is much easier.
I think it's simply much more in line with how people usually work with
Debian packages. We should also keep in mind that someone else might
want to, and might actually have to work with the package, like the
Furthermore, I think having the sources unpacked in the orig.tar.gz
doesn't even contradict the goal of being able to drop the debian
directory onto the DVD. Isn't is sufficient to just include
unpack-stamp in the generated orig.tar.gz (and of course the actual
unpacked hierarchy)? The dependency of patch-stamp on unpack-stamp will
still be there, and if there's nothing yet unpacked, it will just be
However, let me add a word of caution. I will probably have to reduce
my involvement in Debian TeX work in the near future: I'm looking for a
new job, in industry instead of at the university, and I guess this will
mean that, at least for some time until I feel comfortable with the new
life, I'll not be able to do much Free Software work. So please do not
change anything just to make *me* happy, rather do it if I could
convince you (the whole team) that it is better that way.
The same applies for some other suggestions with respect to texlive
packaging that I have in mind, but not yet found time to write them
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)