Re: Automatic Debug Packages
On Wed, Aug 12, 2009 at 11:17:55PM +0200, Joerg Jaspert wrote:
> First, the naming:
> It is indeed us Ftpmasters who want them named .ddeb. For two reasons -
> a simple one is that it makes the handling much easier, if you can match
> on *.ddeb$. Another one is that they aren't "real" debs like .deb. They
> aren't meant for normal user consumption, but only for special
> situations. For most users possibly completly automated and
> transparently in the background. Seperating them as .ddeb helps making
> it clear it is "something different than what you know from usual debian
> packages". More so than a -debug in the name alone.
I don't think this is going to make it very clear to most users (what user
is going to look at the filename?), and so far I don't see much reason that
they should *be* different than .debs.
> Also, ddebs should probably be defined in policy as not having
> maintainer scripts.
That's a reason to document them separately in policy, certainly, though I
don't think this has been mentioned before now as a requirement?
> Second the storage:
> Archive side they will be put into the normal
> directories right beside the source and other binaries from the
> package. They will, however, not be exported to the public view of the
> archive. Instead we will export a second directory which contains them,
> which can then be mirrored seperately from mirrors that do want to have
$ du -sh /srv/ftp.debian.org/ftp
$ df -h /srv/ftp.debian.org/
Filesystem Size Used Avail Use% Mounted on
/dev/cciss/c0d0p1 1.4T 1.1T 205G 85% /
I would guess a full set of ddebs for unstable would take *at least* as much
space as everything currently in the archive (oldstable - experimental). Are
there plans for a hardware update on ftp-master to accomodate this sudden
explosion in archive size?
> Quantity of .ddebs:
> Usually there should only be one .ddeb per source. Of course there are
> always exceptions from the rule, so Maintainers may chose to have one
> per binary package. This should only be taken when the size of the debug
> package gets *huge* otherwise. It is hard to set definite numbers here,
> but a 5mb package would surely not be a reason to split into two 2.5mb
Why should this be the norm?
- they're outside the main archive, so by default the Packages file size has
no impact on the end user
- much of the data in the Packages file should be irrelevant for ddebs
(e.g., short auto-generated Package descriptions maybe?), so even at a 1:1
ratio the ddebs Packages file should be a quicker download for users
- grouping by source package requires an extra indirection when figuring out
the correct ddeb to download (file -> binary package -> source package)
- "Maintainers may choose" opens up a broad range of cases where maintainers
will have to manually implement this, particularly if they want ddebs to
only be installed when the corresponding deb is installed; whereas with
per-binary-package ddebs these cases could be automated.
> The packages do also not need to be listed in debian/control, if they
> follow the "one ddeb per source" general rule. If there are more of them
> then they will need to be explicitly defined.
Why should this be the case?
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/