Re: shared library -dev package naming proposal
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:
>
> 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:
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
Reply to: