[tryton-debian] tarball compression
Raphael Hertzog
hertzog at debian.org
Sat Jan 25 17:15:54 UTC 2014
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/
More information about the tryton-debian
mailing list