Le mardi 11 août 2009 à 16:13 -0700, Russ Allbery a écrit : > > Actually I don’t see the point in this symlink. It only makes things > > more complicated, especially if there is no one-to-one mapping between > > ddebs and debs. > > Without the symlink, they're not valid Debian packages. It seems like a > small price to pay for keeping them consistent with the rest of Policy. The policy is just a document. The question is more about what this symlink would bring. BTW, udebs don’t have a /usr/share/doc directory, so that makes a precedent. > > If we use build IDs (and this has quite some advantages, like being able > > to do more than just dump the ddebs on a repository), this can lead to > > having the same detached debugging symbols in two binary packages, since > > sometimes a binary is built twice the same exact way and put in two > > different binary packages. > > Hm, really? The toolchains that I'm familiar with basically never produce > the same binary twice; something is always slightly different from > timestamp information. Could you give an example of such a case in the > archive right now where identical binaries are in multiple packages so > that I can better understand how this happens? ISTR seeing this with evince/evince-gtk before the plugins were put in a single package for both versions. Anyway I’ll let Emilio answer since he did some testing about that specific issue. > > The consensus on #debian-dak when we discussed this specific issue was > > to use one ddeb for each source package by default, and to let the door > > open to the maintainer overriding this default with several ddebs in a > > source, using a new header in the control file. This way we can keep > > things as simple as possible, without losing the possibility to handle > > corner cases that will arise. > > In this case, I believe that, in order to comply with some of our > DFSG-free licenses, we will have to ship a copyright file in the debug > package. I’m not sure of what is necessary here. How do we deal with that specific issue in udebs? > Also, some source packages are *huge*, and I don't want to have to install > 50GB of debugging information for, say, all of KDE just because I want the > debugging symbols for a single library. I suppose that's why you have the > escape clause of letting maintainers do it differently if they desire, but > there I really would like to see us treat the entire archive identically > if at all possible. The main purpose of setting up an archive of debugging symbols is to be able to use them transparently without installation, so that doesn’t change much. That said, it’s clearly a good reason to allow splitting ddebs manually at the maintainer’s discretion for some of the largest packages. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=