Re: Sourceless but useless: how about ignoring some irrelevant files instead of repackaging?
On Mon, Sep 07, 2009 at 09:01:04PM +0900, Charles Plessy wrote:
> in one of the packages I mainatain, upstream left some zlib and ncurses static
> libraries for Win32 in the source tarball.
IMHO it is always a good idea to remove crap from an upstream tarball.
Static libraries are definitely crap and are just wasting our archive.
So in this case rebuilding the tarball sounds a prefectly reasonable
action if done properly in a get-orig-source target and documented in
> Now I will have to add a lot of stuff to debian/copyright, make a ???dfsg???
I see no reason to rename the tarball to "dfsg" because you did not
changed the *source*. At least I do not remember whether the docs do
require / recommen in best practices such a rename. As I understand
it is rather a matter of taste whether you use this postfix.
> provide a get-orig-source target in debian/rules, and write a
> README.source file to comply with the Policy, and do the repackaging dance at
> each new upstream release. This is not the way I have fun.
If you write a reasonable get-orig-source tarball the effort for
repackaging is low (~ zero).
> Alternatively, I can of course ask Upstream to remove the Windows binaries, but
> how can I convince him that we hurt our users by leaving these files in the
> Debian source packages, while the sources of zlib and ncurses are actually
> distributed by Debian together with the sources of his program?
IMHO it is always a good idea to teach upstream. It is not about
hurting our users - it is about that it's just a bad idea to bundle
precompiled binaries in a source tarball.
> I really wish that we could open a discussion on the possibility to ignore some
> legally redistributable source-less files that are in the .orig.tar.gz upstream
> archive, provided that we do not include them in our binary packages nor use
> them at build time.
I'm not against this discussion in general - but the example above
is not really worth a discussion, IMHO.
> This could also include source-less PDF files, which are
> another time sink in the field where I do my packaging.
Yes, that's what I regard reasonable (but you want the PDF to be
included also in the binary deb - in contrast to the *.a files above).
Klarmachen zum Ändern!