On Tue, Nov 27, 2007 at 09:25:02PM +0000, Ian Jackson wrote:
> [Option D:]
> (1) The existing libconfig in Debian may retain its name.
The maintainer of that package writes:
] Here's my argument(s). I'll try to keep it short:
]
] a) First come, first serve. I'm both the upstream author and maintainer and
] the library is used by several of my programs (some Debian packages, some
] not). I would prefer not to spend all the effort to rename just to please
] another crowd that didn't do the research to check for name clashes to
] begin with.
]
] I think it is definitely unfair to expect me to change the name, even if
] my version is less popular.
]
] b) I agree that the name is perhaps a bit generic and a more specific name
] would have been a better choice.
-- http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=441200
As far as (a) goes, first-come-first-serve is reasonable to some extent,
which is why the "git" package doesn't contain the version control system.
Userbase is relevant too though, and afaics, libconfig doesn't have one. There
are no build-depends on libconfig0-dev in unstable, nor any dependencies on
libconfig0 or libconfig0-dev in unstable.
The libconfig author (Abraham vd Merwe, abz@d.o) is also the maintainer
of libdebug (builds libdebug0 and libdebug0-dev) and libabz (builds
libabz0 and libabz0-dev). All the packages that use libabz are maintained
by Abraham, and all the packages that use libdebug also use libabz.
Both libconfig and libdebug have been unchanged since sarge's
release. libabz has been updated since sarge, but was not released with
etch due to bug 385881.
The extent of changes to libconfig since its initial inclusion in the
archive in June 2002 have been (according to the changelog):
* Ported to library to FreeBSD.
* Changed copyright notices to reflect my new preferred email address.
* Updated feature wishlist.
* Added a more descriptive description in control file (Closes: #151535)
* Changed libconfig0-dev section.
* Updated package dependencies.
* Changed sections.
The changes to libdebug have been somewhat more substantial though not
massively so. libdebug was also first uploaded in June 2002. libabz
was first uploaded in November 2002 (according to the ftpmaster logs,
libconfig and libdebug were both accepted from NEW by Randall Donald;
libabz by James Troup).
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.
> [Options X and N:]
> (1) The existing libconfig in Debian must be renamed or removed.
I'd say the libdebug0/libconfig0 binary package names should be reserved
for the existing libconfig/libdebug packages to ensure there aren't
any dependency breakages, but their source packages should definitely
be removed.
> [Option N:]
> (2) The newer library may use the name libconfig.
> [Options X and D:]
> (2) The newer library may not use the name libconfig.
I'd be inclined towards a name more like "libconfig-hyperrealm" to
avoid being unnecessarily generic, while still making it easy for people
searching for `libconfig'.
The first page of google gives the following results:
#1 hyperrealm libconfig by Mark A. Lindner (the one under ITP)
#2 gnuwin32 port of R. Keene's libconfig
#3 freshmeat page for R. Keene's libconfig
#4 homepage for R. Keene's libconfig
#5 sourceforge page for Zhange Le (ejoy)'s libconfig, a C++ port
of KDE's KConfig
#6 WAND libconfig
#7 & #8 packages.d.o pages for libconfig-ini-perl
#9 this thread (!)
#10 libconfig for the Amaya web browser
Five different projects just called "libconfig" in the top ten results
seems to me to indicate "libconfig" alone isn't a distinctive enough
package name for any of them.
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.
> [All options:]
> (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.
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.
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.
> (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 note Abraham also wrote in the mail referenced above:
] Because of (b) I would be [very reluctantly] willing to rename the package,
] but if and only if an agreement is reach that NOBODY will ever use libconfig
] as a package name.
]
] If I must rename my package, so should the other maintainer/upstream
] developer as the same rule apply to them.
]
] If they're not willing, I'm sticking to my guns.
]
] Please realise that I'm not trying to be difficult. I'm trying to set a
] principle (and I'm lazy (: ).
I found the above pretty counter-productive personally; it seems to
imply that the first person to get a package name has a moral right
to at least exclude anyone else from using it later, which seems very
proprietary and misplaced to me.
In any event, the way I currently see this is:
(1) The existing libconfig in Debian must be renamed or removed.
(2) The existing libdebug in Debian must be renamed or removed.
(3) The existing libconfig and libdebug should be incorporated into
libabz.
(4) The proposed libconfig should be called libconfig-hyperrealm or
similar to distinguish it from other libconfigs.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature