[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#441200: libconfig name clash


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

 3. The alternative is a newer more widely-used C++ library from an
    external author, which has existed for some time.  (`The newer

 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

 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

 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.


 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

 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.


 21. I would therefore rule as follows:


    (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.



Version: 2.6.3ia
Charset: noconv


Reply to: