On 2020-03-13 11:36, Daniel Kahn Gillmor wrote: > On Thu 2020-03-12 23:21:29 +0100, Aurelien Jarno wrote: > > That would clearly work for your use case. Now I am not sure it won't > > break other things. > > I'd like to know what it would break if it would break anything. Anything that take a decision based on the name. So far I don't have any concrete example, and if I can't find any in a few weeks, I might just give a try. But right now we are in the middle of a transition, that's not the moment to break more things. > > I asked on IRC and so far only get the confirmation that the package > > shall not be renamed to libc6-dbgsym. > > Thanks for the reportback. Is there some policy about what kinds of > package may be named *-dbgsym generally that renaming libc6-dbg would > violate? comparing the file lists and (lack of) maintscripts between > libc6-dbg and (as a random example) libglib2.0-0-dbgsym, they don't look > that different (libglib2.0-0-dbgsym ships a file in /usr/lib/debug/.dwz > while libc6-dbg does not, but i don't know that this is an important > difference). The reason is that all *-dbgsym packages need to go the debug archive, not the main archive. We can't rename libc6-dbg into libc6-dbgsym and move it to the debug archive as packages from the main archive currently can't depend or build-depend on packages from the debug archive. This is not something that can be fixed easily by just the glibc team. It would require at least the following changes: - d-i should be updated so that new installations add the debug archive by default. A solution have to be found for the upgrades. - wanna-build and the buildds should be configured to also use that debug archive. - a debug security archive has to be created. Plus I guess changing some policy and/or documentation and policy to explicitly allow a package from the main archive to depend on the debug archive. > Or is the reason that a rename would require updating the dependencies > of other existing packages? For runtime deps, there aren't many: > > 0 dkg@alice:~$ apt rdepends libc6-dbg > libc6-dbg > Reverse Depends: > Suggests: testdisk-dbg > Suggests: libxapian30-dbg > Depends: valgrind > Suggests: testdisk-dbg > Recommends: libntdb1-dbg > |Recommends: libgcj17-dbg > Suggests: ekiga-dbg > Depends: valgrind > Suggests: testdisk-dbg > Depends: valgrind > 0 dkg@alice:~$ > > I'm not sure the quickest way to get a list of build-deps, sorry! It > does seem like a transitional package would be the standard way to solve > this problem, and not a huge pain to do. We've handled much worse > transitions. Again we are talking about different archives. It's not a question of updating the reverse dependencies. > Or is it because it's always been this way, and there's documentation > out there that might get out of date? The documentation would survive > with a transitional package for one release of debian anyway, and at > some point we need to prioritize consistency for new users over > stability of unmaintained documentation. if someone is reading a > 4-year-old unmaintained tutorial on debugging in debian they're probably > not getting the most helpful information anyway. > > Or is there some other reason? No it's not a question of documentation. > I'm sorry to press on this, but "IRC says we shall not do this" sounds a > lot like what people accuse debian of in its worst moments -- reflexive > resistance to change, even when there's a well-motivated reason and a > transition plan available for a concrete improvement, even a minor one > like this. I'm really in the dark here. If there are other reasons, > i'd like to know them. It has not been said about a random person, but by one of the FTP masters. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature