Re: -dbg packages mirror occupation: ~1/3, 220 GB
On Wed, Jun 27, 2012 at 01:07:15AM +0200, Simon Paillard wrote:
> Hello,
>
> Out of ~610 GB of data in mirrors (all archs, source, and arch-indep), there
> are around 230 GB of -dbg packages !
>
> -> The impact is 1/3 of mirror space (that means mirror sponsors cost) is used
> for dbg packages.
>
> Ideas, please comment / propose yours:
>
> * Let mirrors admins exclude dbg ?
> However, while admins have the ability to exclude archs, excluding -dbg would
> not guarantee anymore that a file present in Package.gz of mirror and dist can
> be downloaded for this same mirror.
> It may be handled at this level, redirecting/proxying these dbg files.
Since this breaks the fact that the references from the Packages index
is available at the same host, I'd disagree with that approach.
If there was a debug-<arch> component with is own indexes and all that
stuff, I don't see any issue.
> Involving DD:
> * More compression ?
> After some tests on linux and webkit dbg packages, I cannot see any improvement
> compressing them with xz, even -9, over default gz.
> * Define some guidelines to determine whether building -dbg packages is worth.
Since it is not possible to define when the debug symbols are useful,
this approach is incorrect. I have been, and I assume many others have,
been in situations where it is not feasible to even rebuild a package,
much less rebuild it with debugging symbols and reproducing the
scenario.
In fact, we should aim to make them available for *all* packages.
> Involving ftpmasters:
> * Split to another archive, similar to the data.debian.org project ?
My proposal is a mix of that (a separate archive) along with a service
where one can submit core dumps and have the server build the
backtrace.
Depending on the scenario, either the archive should be used to
retrieve the dbg packages (or ddbebs, as it was proposed at some point
IIRC), or the core dump submitted. For instance, if your news/feeds
reader crashes the core dump could just be uploaded along with some
metadata and the backtrace could be returned by the server.
Since the submissions server requires more work on the client and
server sides, why not just go for the common divisor, which is
generating the symbols for all packages and putting them in a separate
archive?
One interesting thing that needs to be taken into consideration is the
recently-introduced buildid. Should the archive serve the symbols in
traditional deb files? should it serve the compressed by-buildid
symbols?
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: