Hi, > 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 >
You have a point, that probably makes libfoo-dev being a unversioned provides to be a problem. > > 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? Currently, it's unordered. Say a shared library package has the following: libfoo-0.1-0 The development package looks like one of the following or another random incarnation: 1. libfoo-dev 2. libfoo-0.1-dev 3. libfoo-0.1-0-dev 1 and 2 cannot easily be deduced from the shared library package name, and I am proposing using 3 as a means of deducing the -dev package name. However, the goal of "having an information to shared library package name with development package name" can be achieved by having the package name in the "Provides:" field, so that might be a less disruptive approach. BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]