Bug#441200: libconfig name clash
Here's my latest draft of a libconfig resolution. No-one seems to be
suggesting that either package is entitled to the name so I have
removed that option.
Thanks to AJ for detailed feedback. I've taken out the process for
the TC approving names and replaced it with a request to the
ftpmasters. I've also made the process clearer, by ensuring that
inactivity by the existing libconfig maintainer would not block the
removal of the old-named package.
I've added a recommendation about libdebug, and one about other
distros. If those latter two prove controversial they can come out
again.
Ian.
-8<-
To the maintainers and ftpmasters:
(1) The existing libconfig in Debian must be renamed or removed.
The ftpmasters should remove it from sid right away; the
maintainer may upload a renamed version (but see (4) below).
Any packages in sid which depend on libconfig and remain
unfixed within 4 weeks should also be removed from sid.
(2) The newer library may not use the name libconfig either.
To the ftpmasters:
(3) When the renamed packages from either maintainer are processed
through NEW, please ensure that the new names are clear,
descriptive, and unlikely to cause further clashes. For
example, libconfig-hyperrealm would be a good name which
distinguishes the library under ITP from other libconfigs.
`libconfig1' is not an acceptable replacement name.
To the libdebug maintainer:
(4) We recomment that the current libdebug in Debian should also be
renamed or removed, for example by folding both it and the
existing libconfig into libabz.
To other Linux distributors, and to the ITPer:
(5) We recommend that Mark Lindner's libconfig should be packaged
in Linux under a more descriptive name, preferably one agreed
by the parties and accepted in Debian. We encourage the Debian
maintainer to take responsibility for these negotiations.
-8<-
NB THIS IS A DRAFT BALLOT - THERE HAS NOT YET BEEN A CFV
[ ] Choice N: Neither package may use the name `libconfig'
[ ] Choice F: Further discussion
1. This is a dispute about who should be allowed to use the name
`libconfig' (both as a library name as in -lconfig and in the
package name).
2. The existing libconfig in Debian (`the existing library') is old,
not widely used (has no reverse dependencies) and has only 40
installations listed in popcon. It is packaged as a Debian-native
package.
3. The alternative is a newer more widely-used C++ library from an
external author, which has existed for some time. (`The newer
library'.)
4. `config' is not a very distinctive name. Just as we do not like
command names which are simple words or the most common
abbreviations thereof, we do not like simple undistinctive library
names like `libconfig'.
5. A web search for `libconfig' gets references to the newer library
but also many references to 5 other libraries called libconfig
(both published libraries and private parts of publicly
distributed projects).
Basis for deciding
6. There are several possible considerations which might guide us
when resolving a name clash:
7. The most obvious is the balance of convenience. Which way will
produce the least overall problems given the situation we
currently find ourselves with ?
8. We must in my opinion also consider whether the name is more
appropriate or relevant to one program or the other.
9. However, as a decisionmaking body we should also encourage good
practice in general . To do otherwise would give namespace
landgrabbers carte blance to create `facts on the ground' (as is
sometimes said in international relations).
(1) Good practice includes choosing a distinctive and appropriate
name in the first place. However in cases of a conflict the
two groups will typically already have failed to do so.
But, good practice would also often include:
(2) Paying attention to documentation and policies which ought to
have influenced the choice of name;
(3) Choosing a long and unique name for what is likely to be a
program of narrow, specialised or local interest.
(4) Searching for existing uses of a name before committing to it.
(5) Ensuring that one's name, once chosen, will show up in such
searches and/or paying attention to possible future conflicts
if feasible.
This isn't an exhaustive list.
10. We should in my opinion balance these three kinds of
considerations.
11. We are, I think, entitled to decide that neither intended user is
entitled to the name. We should have regard to all of the above
factors in this case, and also the likelihood of future conflicts
arising.
The Current Question
12. Hardly anyone will be inconvenienced if the existing library is
renamed. The maintainer will need to do a small amount of work,
or to allow the package to be removed. It is likely that all
references to the existing library can be updated with a small
investment of time and effort.
13. We are not very likely to be able to persuade the newer library's
upstream to rename it at this point. As a result, insisting on it
having a different name in Debian would cause some inconvenience
to any users of the library and is likely to result in ongoing
confusion. However, we may be able to persuade other Linux
distributors to provide it under a different name.
14. Renaming the newer library in Debian would benefit the users of
the other libconfigs, including projects and sites which use the
name `libconfig' for internal libraries; it is hard to know how
many such projects there are and we might not be aware of any
clashes. A quick search shows that a piece of software called
`libpqxx' renamed an internal header it called `libconfig.h'
probably for this reason.
12. Neither library has a particularly good claim to this name.
13. The existing library's author has failed on many of the counts of
good practice. Debian policy documents discuss namespace
conflicts in the context of command names, which while not
directly on point ought to have alerted the library's author to
the potential problem. The library is extremely parochial and so
needs an especially distinctive name. Obviously the existing
library came first but even a cursory web search at the time would
probably have revealed prior private uses elsewhere which would be
at least as interesting. The steward of the existing library
seems to have been largely oblivious to the problem and has not
made a concerted effort to defend the name.
14. The newer library's authors have also failed. As a standalone
project they do not have the benefit of our policy documentation
to guide them away from these kind of problems. Their library is
intended to be of general applicability and interest, which
mitigates the poor choice of name. However, there is no evidence
that the authors did a web search for the name; if they had done
they would have found otherr uses of the name and probably the
existing library in Debian.
Conclusions
15. All of the factors - particularly the parochial nature of the
existing library - suggest that the existing library has very
little basis for keeping the name.
16. Whether the newer library should be allowed to complete this
namespace landgrab is less clear. On the basis of convenience the
decision would be unclear; propriety would suggest no.
17. In any case I would err on the side of propriety.
Choice of replacement names
18. The new name (if any) chosen by the existing library should
ideally contain the name of the author, their site, or some
similar parochial identifier.
19. The new name for the newer library should include something which
will distinguish it from other libraries suitable for
configuration.
20. It is necessary to ensure that the chosen new names do not
themselves cause problems. We would like to avoid a heavyweight
procedure for approving the new names but have an opportunity to
stop the use of an inappropriate name. It is most expedient to
have the ftpmasters enforce this during NEW processing.
Ian.
Reply to: