[tryton-debian] tarball compression

[Raphael Hertzog]

Hello Mathias,

I recently joined the list as I started using Tryton for my company. I
can probably sponsor some of your uploads. In the short term, I'm
particularly interested in tryton-account-fr. :)

Cheers,

On Sat, 25 Jan 2014, Mathias Behrle wrote:
> * 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



> _______________________________________________
> tryton-debian mailing list
> tryton-debian at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/tryton-debian


-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/