Re: Automatic Debug Packages
Manoj Srivastava <srivasta@debian.org> writes:
> So policy is going to prohibit contrib or non-free packages
> with debugging symbols (or, at least, debug packages that may use the
> common nomenclature)? This seems kinda drastic. So the packages with
> debug symbols from those sources will continue to live in the primary
> archive, and not go into the specialized debug area,
The second bit, not the first bit, would be the implication, I think. I
don't really care one way or the other -- I just want it to be clear.
> The only way this can arise is if you build once, and copy the
> same files into two conflicting packages. Silly, but nothing in policvy
> prohibits it as long as the packages either conflict or put the files
> in different locations.
Hm, that raises an interesting point: shouldn't we be duplicating the
Conflicts from the binary packages to the corresponding debug packages
with a transform applied to the package names to convert them to the debug
package names? Otherwise, debugging symbols for packages that don't use
the id method are going to have file conflicts with other debug packages
for packages providing the same binary.
> Personally, I think that one debug package per binary package
> makes more sense, and the optimization for duplicate files in multiple
> packages is likely to be too small to be worth considering; and we can
> have the header revert the decision: one debug file/binary, unless the
> user specifies that theres should be one giant debug package (and I am
> not sure how many packages will need to do this because they ship
> duplicates anyway.
I'm okay with that as long as we require a copyright and changelog file in
the debug package if it doesn't meet the criteria for a /usr/share/doc
symlink (which will be basically any debugging package for an entire
source package, I think).
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: