Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
On Fri 2020-03-13 17:22:30 +0100, Aurelien Jarno wrote: > The reason is that all *-dbgsym packages need to go the debug archive, > not the main archive. Thanks, this is the piece of information that i was missing. Where is it documented that all *-dbgsym packages need to go to the debug archive? --dkg signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
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 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
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. > 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). 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. 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? 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. Thanks for all your work in maintaining such a critical part of debian! Regards, --dkg signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
On 2020-03-11 20:31, Daniel Kahn Gillmor wrote: > On Wed 2020-03-11 21:42:43 +0100, Aurelien Jarno wrote: > >> Every other debug symbol package in debian is named $foo-dbgsym. libc6 > >> seems to be the exception. > > > > Well libc6-dbg is not a standard dbgsym package: > > - It is a dependency for other packages > > - It is a build-dependency for other source packages > > - It is not an automatic debug package (ie using debhelper) as we need > > to strip libpthread.so and crt*.o differently. This means that the > > resulting package do not have the same properties. > > Thanks for outlining these differences. I expected that it would indeed > be different from others due to the unique position of libc, but i > didn't know the details. > > >> Can we please rename this package (along with a transitional package to > >> help folks upgrade from libc6-dbg) and set up an appropriate Provides: > >> at least? > > > > With all the above said, I am not sure it's something we can do. However > > I don't know who can actually answer that question. > > What about just adding a Provides: libc6-dbgsym to the package? That > should make it findable at least, for people who are now used to the > convention that foo's debug symbols are in foo-dbgsym. That would clearly work for your use case. Now I am not sure it won't break other things. I asked on IRC and so far only get the confirmation that the package shall not be renamed to libc6-dbgsym. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
On Wed 2020-03-11 21:42:43 +0100, Aurelien Jarno wrote: >> Every other debug symbol package in debian is named $foo-dbgsym. libc6 >> seems to be the exception. > > Well libc6-dbg is not a standard dbgsym package: > - It is a dependency for other packages > - It is a build-dependency for other source packages > - It is not an automatic debug package (ie using debhelper) as we need > to strip libpthread.so and crt*.o differently. This means that the > resulting package do not have the same properties. Thanks for outlining these differences. I expected that it would indeed be different from others due to the unique position of libc, but i didn't know the details. >> Can we please rename this package (along with a transitional package to >> help folks upgrade from libc6-dbg) and set up an appropriate Provides: >> at least? > > With all the above said, I am not sure it's something we can do. However > I don't know who can actually answer that question. What about just adding a Provides: libc6-dbgsym to the package? That should make it findable at least, for people who are now used to the convention that foo's debug symbols are in foo-dbgsym. --dkg signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
On 2020-03-11 15:33, Daniel Kahn Gillmor wrote: > Package: libc6-dbg > Version: 2.29-10 > > Every other debug symbol package in debian is named $foo-dbgsym. libc6 > seems to be the exception. Well libc6-dbg is not a standard dbgsym package: - It is a dependency for other packages - It is a build-dependency for other source packages - It is not an automatic debug package (ie using debhelper) as we need to strip libpthread.so and crt*.o differently. This means that the resulting package do not have the same properties. > Can we please rename this package (along with a transitional package to > help folks upgrade from libc6-dbg) and set up an appropriate Provides: > at least? With all the above said, I am not sure it's something we can do. However I don't know who can actually answer that question. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#953654: libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
Package: libc6-dbg Version: 2.29-10 Every other debug symbol package in debian is named $foo-dbgsym. libc6 seems to be the exception. Can we please rename this package (along with a transitional package to help folks upgrade from libc6-dbg) and set up an appropriate Provides: at least? This can be a stumbling block for people trying to get software development work done on debian, as evidenced by me screwing up over here: https://lists.debian.org/debian-powerpc/2020/03/msg00029.html --dkg signature.asc Description: PGP signature
