Manoj Srivastava <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
