[tryton-debian] tarball compression (was: DM for python-sql)

[Mathias Behrle]

* Andreas Tille: " Re: [tryton-debian] DM for python-sql (was: Migration to
  alioth)" (Thu, 12 Dec 2013 18:22:11 +0100):

Hi Andreas,

first: I put you on CC while checking, that you are not subscribed to this
list. Is this ok?

> On Wed, Dec 04, 2013 at 11:54:07AM +0100, Mathias Behrle wrote:
> > > 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.
> > 
> > The reason for me is as obvious as it can be;):
> > The discussion of reducing load of bandwith and space on the mirrors and
> > installation media dates from before Debconf 2012. Daniel changed
> > proactively the layout of the Tryton packages. With dpkg meanwhile using xz
> > compression as its default,
> 
> Yes, this is nice.
> 
> > it is even more as logic for me to use the same compression for the
> > orig tarball.
> 
> This is not a logical consequence.

I am missing this point. Why do you think the default compression method of dpkg
was changed? 

There are continous messages, that space on alioth is at its limit, currently:
/dev/mapper/moszumanska-srv           609984912 575047500  28743616   96% /home

The average space saving for a tarball of the Tryton packages is about half the
size.
- This is an enormous space saver (s. alioth, archive, etc.)
- This is an enormous traffic saver (e.g. with respect to the rather poor upload
  I am facing with the provider Telekom even in a city this *is* a noticeable
  benefit)

> > Reading [1] "Specifying better compression method: ...the author
> > is tempted to turn default to xz. " points even further in this direction
> > and this is written AFAICS by you ;).
> 
> This is part of my UscanEnhancement and it is *only* if there is any reason
> for repackaging (like files to remove or if upstream has *.zip or so).
> 
> > So if you would accept xz (re)compression for a substantially changed
> > tarball, why wouldn't you accept it for an unchanged tarball?
> 
> I explained this previously and I have no idea how to explain it again.
> If you are keen on other explanations please ask on debian-devel /
> debian-mentors.
> 
> > In other words: if I would
> > decide to remove the .egg files from the upstream tarball (as discussed as
> > one possibility in[2]), you would accept the procedure, but just
> > recompressing the tarball not? 
> 
> If there are valid reasons for changing the tarball (for instance to
> remove files - I wouldn't call the discussion at [2] really a consensus
> but that's not me to decide) than for sure I agree with a different
> compression method.  In this case you should also rename the tarball
> (the just released devscripts are containing Files-Excluded which also
> does the renaming but it seems specifying the compression method
> specification is delayed for the next version).
> 
> > You sent me to d-devel to discuss this question. On one side I am really
> > concerned to increase the load on d-devel with such (for me) nitpicking
> > questions (until now no ftp master ever lost a word with respect to Tryton
> > packages, neither in NEW nor in the archive),
> 
> May be they just did not noticed (like me before).
> 
> > on the other side I only will
> > open questions, if I am able to participate ad hoc in the discussion. The
> > latter not being the case currently, because my time slice for the work on
> > Tryton in Debian is more than exhausted those last weeks. So if you
> > absolutely insist on clarification on d-devel, this will be for a later
> > moment.
> 
> I see no point in discussion each others time constraints.

I am saying this to give feedback, not to discuss.

> I'm doing
> the sponsering to the best of my knowledge and over several years I of
> Debian packaging I have considered as consensus (and I'm sure the
> packaging docs are reflecting this) that you should try to stick to the
> original upstream source if possible.  If I face a sponsoring request
> that does not fit my knowledge of good packaging practices I will not
> upload.

This is your responsibility as sponsor and I wouldn't do it in a different way
myself. So thanks again for the work you are doing.

Cheers,
Mathias

-- 

    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/20131213/21009112/attachment.sig>