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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]