On Fri, Oct 2, 2015 at 3:55 PM, Mathieu Malaterre <ma...@debian.org> wrote:
> On Fri, Oct 2, 2015 at 2:12 PM, Emilio Pozuelo Monfort <po...@debian.org>
> wrote:
>> On 02/10/15 14:02, Mathieu Malaterre wrote:
>>>> Your -dev package went from libdcmtk2-dev to libdcmtk4-dev. That makes
>>>> transitions too painful as every reverse dependency needs a sourceful
>>>> upload to
>>>> change the build dependency, instead of the release team just scheduling
>>>> binNMUs
>>>> as is normally done.
>>>
>>> Here is how this is done:
>>>
>>> [...]
>>> Package: libdcmtk2-dev
>>> Section: libdevel
>>> Architecture: any
>>> Depends: libdcmtk2v5 (= ${binary:Version}), ${misc:Depends},
>>> ${shlibs:Depends}
>>> Conflicts: libdcmtk1-dev
>>> Replaces: libdcmtk1-dev
>>> Provides: libdcmtk-dev
>>> [...]
>>>
>>> So if third party libs requires explicit `libdcmtk2-dev`, then the
>>> issue is within there own package. AFAIK there is nothing wrong with
>>> this scheme.
>>
>> What's wrong is that you're making everybody b-depend on libdcmtk2-dev
>> because
>> that's the package name - even if people could b-d on libdcmtk-dev, because
>> maintainers probably don't even know your package provides the non-versioned
>> package name.
>
> Your sentence seems to contains a contradiction IMHO. You have a very
> strict understanding of `serious` issue.
Forgot to quote section ยง8.4 Development files
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev
[...]
If there are development files associated with a shared library, the
source package needs to generate a binary development package named
librarynamesoversion-dev, or if you prefer
[...]
