[tryton-debian] tarball compression

[Mathias Behrle]

* Mathias Behrle: " Re: [tryton-debian] DM for python-sql (was: Migration to
  alioth)" (Sat, 11 Jan 2014 19:51:02 +0100):

Hi Andreas,

just asking, not urging: did the mail below come to your mind?

Cheers,
Mathias

> * Andreas Tille: " Re: [tryton-debian] DM for python-sql (was: Migration to
>   alioth)" (Wed, 4 Dec 2013 08:53:53 +0100):
> 
> Hi Andreas,
> 
> > PS: I have not forgotten tryton-modules-timesheet-cost but I'm waiting
> >     for an answer about the recompression issue.  I will not upload
> >     until you give acceptable reasons why you did the recompression which
> >     is IMHO not conform to Debian policy.
> 
> Reading back and forth Debian policy I couldn't find any reference to the
> compression of the orig tarballs. Perhaps you could point me in the right
> direction, if I missed something.
> 
> The only reference I found to this subject is in the Debian Developers
> Reference [1], which contains explicitely 'shoulds', but not 'musts'.
> 
> So I am trying once more to convince, that the current way is ok
> with regard to Tryton repositories:
> 
> The main and only reason to have a valid checksum on a source tarball is,
> that you intend to reuse the remote tarball for packaging/build purposes. This
> is exactly not the case with sourcefull git repos as the Tryton git
> repsoitories are. When importing the original source into this kind of
> repos, the source is immediately forked completely from the upstream source
> (which IMHO is one of the very good reasons to do so). From now on you are
> building from the forked sources, independent from further availability and
> integrity of the remote source tarball. The source for packaging is the one
> provided by the pristine-tar branch, and nothing else. And this one must be
> byte-to-byte identical to the one uploaded to the archive.
> 
> Finally I think, that this is justification enough to qualify as good
> packaging practice:
> 
> - Complete fork of the original source
> - Persistent and permanent availability of the sources independent from
>   upstream sources (AFAIS also an advantage in legal aspects, because we
>   redistribute GPL and thus are able to provide the sources either in the
>   packaging VCS or on the archive)
> - Advantage of reducing bandwidth by compressing to a state-of-the-art
>   compression
> 
> At least for me this seems not to be a policy question, why I currently see no
> reason to escalate to d-devel.
> 
> Could you please re-evaluate on the base of given arguments?
> 
> Thanks,
> Mathias
> 
> [1]
> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz
> 
> 



-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/tryton-debian/attachments/20140125/0eafca56/attachment.sig>