[tryton-debian] DM for python-sql (was: Migration to alioth)

[Mathias Behrle]

* 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/20140111/8aedc464/attachment.sig>