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
README.source.

> Now I will have to add a lot of stuff to debian/copyright, make a ???dfsg???
> tarball,

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).
 
Kind regards

       Andreas. 

-- 
http://fam-tille.de
Klarmachen zum Ă„ndern!


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to