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


Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurel...@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: PGP signature

Reply via email to