Junichi Uekawa <[EMAIL PROTECTED]> writes: > Hi, > >> > I'd like to propose, for new -dev packages, to >> > name -dev packages after their runtime library counterparts. >> > >> > If the library package is named lib$NAME, >> > call the -dev package lib$NAME-dev. >> [...] >> >> Hej, >> The obvious downside of this is that the name of dev-package will change >> although the API did not necessarily change. This would increase >> workload for stuff like the current C++ transition and makes backporting >> more difficult. > > Thanks for pointing these points out. > My impression is that your point can be addressed as follows: > > 1. libwhateverXXX-dev can (and in most cases must) provide > (and conflict) with libwhatever-dev, > so the first point is moot. > > 2. However, versioned depends will suffer, but having a versioned > depends will make moot the problem with backporting and C++ transition.
You can (and it is often done) extend an api to include more functionality without breaking the existing api. Any program using one of the new functions must use a versioned depend on the libfoo-dev package introducing the function. The API can (and will) even stay compatibly across ABI changes like the c++ transition or changes in one of the sub libarries. So having an unversioned provide is quite unsatisfactory and having versioned depends on the libfoo-dev quite common. Lets do a very rough count: [EMAIL PROTECTED]:~% grep-dctrl -F Build-Depends "dev (" /mnt/mirror/debian/dists/sid/main/source/Sources -sPackage | wc 1663 3326 31941 > There may be other showstoppers. > > I would really like this 10-year old non-regulation to > go to a concensus (it is indeed rather embarassing we don't > agree on a good solution after 10 years...) It has worked for the last 10 years so why change it now? Till now you seem to only show your nameing scheme isn't worse but not why it is better. Or can you show any problems in the current names? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]