On Sun, May 13, 2012 at 06:47:01PM -0400, Joey Hess wrote:
> Adam Borowski wrote:
> > Could you please mention which ones do not? And if so, how are they
> > relevant/are they fixable?
>
> As one of the maintainers of debootstrap, I am perhaps more aware than
> some how broadly it's used. Ok..
>
> They use it on [lots of stuff].
Ie, the problem is not in d-i, but in running debootstrap on foreign
systems. And that's indeed not easily fixable :(
> > Special-casing base packages would be a lot of complexity, let's avoid that
> > if possible -- but still preferred to letting gzip stay.
>
> Base packages can be identified at build time by their priority.
> if ($priority ne 'important' && $priority ne 'required') {
> }
That's overinclusive (not a fatal problem), and could be potentially
underinclusive (when a base package switches to a library of a lower
priority), but it's still a viable short-term solution.
> Although I do think that rebuilding the entire archive at this point in
> the release process is probably going to result in a lot of ..
> complexity.
I believe even the usual pre-release flurry of uploads would free enough
space, and if not, nudging a few big packages would. There's no need to
recompress EVERYTHING now. And as time goes, gzipped binaries would
gradually die out.
On the other hand, recompressing existing packages is not a good idea in any
place that can simultaneously see both files, and with apt-cdrom, that's
any. Ie, this possibility is out.
> For one, d-i relies on being able to unpack firmware .debs
> The code that does this doesn't support data.tar.xz.
I've seen your commits, so I guess this problem is no more. Thanks :)
--
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon
Attachment:
signature.asc
Description: Digital signature