Re: shared library -dev package naming proposal
Junichi Uekawa <dancer@netfort.gr.jp> 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:
mrvn@frosties:~% 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
Reply to: