On Thu, Nov 29, 2007 at 08:15:47PM +0000, Ian Jackson wrote: > So just to be clear, you conclude as I did that both packages should > be required to select new names ? Yes. I can't see any technical reason whatsoever not to do that. > > 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. Huh? That just seems daft -- it's not a different name at all, it's just the package name for libconfig with a .so version of 1... I can't see any record of anyone suggesting that though, and I'd really hope that it wouldn't be accepted at NEW. Abraham, Julien, do you have sensible alternative names for your packages (eg, incorporating the existing libconfig into the libabz package, or renaming the new libconfig package to libconfig-hyperrealm)? If so, what are they? > 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. I would have thought this was already the case for _all_ packages, and that libdebug and libconfig being accepted in the first place under those names was a mistake. It's a bit long ago to really review now though. > > 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'. Yes. > 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. I'm afraid I'm struggling with incredulity that we even need to deal with that... NEW processing should deal with it, and the maintainers involved should be able to figure out that "libconfig1" isn't going to work... > > In any event, the way I currently see this is: > > (2) The existing libdebug in Debian must be renamed or removed. > You're suggesting overruling the maintainer of this package, I take > it. Sorry, I meant "this is what I think", not "this is what I think the tech ctte should rule".The libdebug package has way too general a name. > > (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. No, hence the "should" instead of "must". > > (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. If we have to choose a name (and can't rely on NEW processing or the maintainers to work how they're supposed to), I'm inclined to think we should just pick some ourselves. Cheers, aj
Attachment:
signature.asc
Description: Digital signature