[tryton-debian] tarball compression (was: DM for python-sql)
Mathias Behrle
mathiasb at m9s.biz
Fri Dec 13 09:34:46 UTC 2013
* 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>
More information about the tryton-debian
mailing list