[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: shared library -dev package naming proposal


> 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:
> mrvn@frosties:~% 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:


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

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.


Reply to: