Re: Bug#441200: libconfig name clash
Anthony Towns writes ("Bug#441200: libconfig name clash"):
> [stuff]
Thanks for that research, which is useful and interesting.
So just to be clear, you conclude as I did that both packages should
be required to select new names ?
> AFAICS neither libdebug nor libconfig have any reason to be packaged
> separately from libabz. I don't think they should have been accepted
> with such generic package names in the first place.
Quite so.
> I don't see any way in which a more descriptive package name would
> cause a problem. Actually, I see the Debian packaging included in the
> upstream source already calls it "libconfigduo". Renaming the library
> itself from libconfig.so.5 would be more of a problem since it'd mean
> binary incompatabilities with other distros. But I don't think that's
> actually an issue, as long as the libconfig packagers make sure they
> don't have .so name conflicts.
If we pick a better name we may be able to persaude at least some
of the more enlightened other distros to come along with us.
> If either maintainer *wants* to use a different package name, they should
> just upload it to NEW, and the technical committee shouldn't even consider
> being involved unless there's an actual dispute about that name.
The problem is that without at least some controls the maintainers are
quite likely to pick poor replacement names. We've had at least one
of them propose `libconfig1' which I'm sure you'd agree is bad.
Would you like to suggest a way that this problem could be solved that
would be acceptable to you ?
One option would be for the TC to explicitly ask the ftpmasters to be
especially fussy with the replacement names. For example:
N. The Committee asks the ftpmasters, when they process the
resulting packages from either maintainer through NEW, to ensure
that the new names are clear, descriptive, and unlikely to cause
further clashes. For example, we would request that the
ftpmasters reject a package named `libconfig1'; names like
`libconfig-hyperrealm' are to be preferred. The individual
members of the committee would be happy to be consulted, and if
requested the committee will of course make a formal decision.
> I don't support the technical committee being involved unless there's
> a clear lead; and even if I'd otherwise support the resolution, I'll
> vote against it if it tries to expand the technical committees influence
> where it's not clearly needed.
I'm not sure what you mean by `clear lead'. Perhaps you mean `clear
need'. I don't have a problem with restricting the scope of the
decisive part of the TC's formal ruling, provided that we can come up
with some way to avoid the substitute names being just as poor.
> > (6) This process applies to each package rejected the use
> > of the name `libconfig' by (1) and/or (2) above; it
> > applies to library names, filenames, package names, and all
> > similar names and identifiers.
>
> I don't think that's useful. Conflicting functionality is
> covered by policy already in general, and forbidding the use
> of /usr/lib/libabz/libconfig.so as a filename or similar seems
> undesirable. Rewriting the clause to be more precise doesn't seem useful
> to me.
I don't see what you mean by your reference to policy. Which bit of
policy did you have in mind ? It seems to me that all kinds of name
clashes are within the purview of the TC - filenames and library
sonames as well as package names.
Note that library names are generally part of a single namespace even
if the filenames are different, because of the way linking works. If
you want to link both libconfigs into the same program. For example,
if you have two separate plugins to a larger application, each of
which uses one of the two libraries, the dynamic linker will only
load one of them if they have the same soname.
> In any event, the way I currently see this is:
>
> (1) The existing libconfig in Debian must be renamed or removed.
I agree with this.
> (2) The existing libdebug in Debian must be renamed or removed.
You're suggesting overruling the maintainer of this package, I take
it. I would be happy to mandate that in principle but it's not clear
how that sits with our constitutional requirement not to make
decisions except as a last resort.
> (3) The existing libconfig and libdebug should be incorporated into
> libabz.
I would be happy to recommend this as formal part of our decision but
I don't think we would want to overrule the maintainer.
> (4) The proposed libconfig should be called libconfig-hyperrealm or
> similar to distinguish it from other libconfigs.
I agree with this. How do you think we should word this part of our
decision to make it clear what we mean ? See above.
Ian.
Reply to: