-----BEGIN PGP SIGNED MESSAGE-----
No-one else on the committee has commented on this issue at all. Do
you have any opinions ?
Here is my draft, which I'm not proposing formally as yet:
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 mainly references to the newer
library - but also some other uses of the name as 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 unlikely 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 considerable
inconvenience to any users of the library and is likely to result
in ongoing confusion.
14. Renaming the newer library in Debian might benefit 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 but not so
seriously. 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. There is no evidence that the authors did a web search for
the name; if they had done they would have found a few internal
libraries 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. Convenience would suggest yes,
whereas propriety would suggest no.
17. 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. The proposed name
`libconfig1' for the newer library is not appropriate.
Decision
21. I would therefore rule as follows:
-8<-
(1) The existing libconfig must be renamed or removed.
(2) The newer library may not use the name libconfig either.
(3) Each maintainer is invited to suggest one or more new
name(s), within 14 days of this resolution.
(4) If after that no member of the TC objects to a name within 7
days (counted from the maintainer's suggestion), then the
package is entitled to the name.
(5) Even if a TC member objects, if the TC does not pass
a resolution vetoing the new name within 28 days, the
package is likewise entitled to the new name.
(6) This applies to both packages; it applies to library
names, filenames, package names, and the like.
(7) Suggestions and objections are to be sent to this bug.
-8<-
Ian.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBRzypdsMWjroj9a3bAQF5zAP/dz8QFd0NTctHm1bj24cBbeqiB+bThAN0
FK0eSQu7ggat8ePLb17Ow4EUY7n0sA5L1zGymymTS0hoL9sYxE0VPUrmeF5AAdhH
BrzDUyBJWL8AOTUA+NovUWWgPrBS+O4e5rsXd9i6BahIgKQPE65UW1HV+Yw5jhCo
GFVouzR5YEU=
=d7K0
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
