Re: -dbg packages mirror occupation: ~1/3, 220 GB
On Fri, 29 Jun 2012 22:54:06 +0000, Raphael wrote in message
<20120629225406.GA3702@debian.org>:
> 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.
..a detail; do we append "debug" to each /etc/apt/source.list line?:
deb http://192.168.1.3/debian sid main contrib non-free debug
deb-src http://192.168.1.3/debian sid main contrib non-free debug
(Of course assuming I carry the debug stuff on my lan mirror.)
..that may need _at_least_ one edit per line?:
deb http://192.168.1.3/debian sid main contrib non-free
# debug
deb-src http://192.168.1.3/debian sid main contrib non-free
# debug
...or do we prefer separate debug lines like e.g.?:
deb http://192.168.1.3/debian sid main contrib non-free
deb-src http://192.168.1.3/debian sid main contrib non-free
debug http://192.168.1.3/debian sid main contrib non-free
..where one easy edit is enough?
deb http://192.168.1.3/debian sid main contrib non-free
deb-src http://192.168.1.3/debian sid main contrib non-free
# debug http://192.168.1.3/debian sid main contrib non-free
..or, do we simply tell end users to use " -t debug " without
forcing new /etc/apt/source.list lines down their throats?
> > 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,
--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
Reply to: