Emilio Pozuelo Monfort <poch...@gmail.com> writes: > Russ Allbery wrote:
>> * These packages are normal Debian packages with normal package metadata, >> but will generally have a symlink in /usr/share/doc/<package> pointing >> to the package for which they provide debugging information. > We haven't agreed on whether there should be one ddeb per source or per > binary package, so I would leave this still opened. Okay, although I certainly hope that we can agree on that. >> * They will go into a separate "debug" archive area, so the Section of >> such packages will be debug/<foo> where <foo> is the section of the >> corresponding binary package for which they provide debugging data. > > Not sure about the archive area bit. What I talked with the ftpmasters > was that they would be in a totally different archive, so instead of > "ftp.debian.org/debian unstable main", you would have something like > "ftp.debian.org/debian-debug unstable main". I don't think that's an > "archive area" in Policy terms. It's not. Sounds like we need some input from ftpmaster here about how this will be handled. I would have thought it would be easier on the dak side to use an archive area rather than a separate archive, but that would solve the problem for contrib/non-free. >> * Those packages must be listed in *.changes like any other packages that >> are part of an upload. They may or may not be present in debian/control >> and in *.dsc depending on the mechanism the package maintainer uses to >> generate them. > > I guess that doesn't imply they need to be listed in Binary and > Description, but that Files and Checksum-* are enough? If so, perfect. They need not be listed in Binary. I'm not sure if they'd need to be listed in Description if we use an archive area, since that gives the archive area to use, but it may be that dak can just special-case that based on the package name. >> * Can we limit this package namespace to *only* detached debugging >> symbols, not all the other sorts of debugging packages that people >> create with special compiler options or optional code features? > > Why should we limit it? There currently are about 85 python -dbg > packages. A lot more could be added. Why limit .ddebs to ELF binaries? > Same for mono, I've added a (trivial) patch to dh_clistrip to support > ddebs. We would gain support for many packages with exactly zero changes > (or just a change to remove the -dbg where they exist). What are the > benefits of such a limitation? If you can produce a specific enumerated list of things like Python debugging symbols and Mono debugging symbols that can go into these packages, and the paths into which such things go, I'm okay with documenting all of that. If, however, these packages are just full separate Debian packages that could contain anything at all the maintainer wanted to put in there, such as binaries built with different options or with trace flags enabled by default, I'm opposed to this proposal. I don't think such packages should be treated specially in Policy at all; at that point, they're just normal Debian packages that should be listed in debian/control like any other and the Policy change should be limited to adding a new section or archive area for them if appropriate. I don't think packages should get any special treatment or blessing, and certainly not automated construction by helper programs, unless they are known to contain a precise and limited type of information and never anything else without a Policy change. Otherwise, we have two classes of packages for no particularly good reason, and we should instead just treat them all as regular Debian packages, some of which possibly going into a separate archive area. >> * What about contrib and non-free packages? Do they just lose here? > If it's legal to ship debugging symbols for them, I can't see why we > couldn't support them normally. The point is that you can't do this with an archive area, at least using the simple algorithm I proposed above. >> * Can we require a one-to-one correspondance between binary package names >> and debug package names that provide symbols for that binary package? I >> think we should; I think it would make the system more straightforward. > > I guess the Packages file could grow a "Has-DDeb: yes" line (or the > Sources file if we go for one ddeb per source package). I suppose, but that seems unrelated. The debugging package archive or archive area will have its own Packages file, and it seems fairly obvious to me that that Packages file should list all the debug packages like a normal archive Packages file. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
