[Debian-med-packaging] Bug#800481: dcmtk: versioned -dev package makes transitions too painful

Mathieu Malaterre malat at debian.org
Fri Oct 2 13:57:14 UTC 2015


On Fri, Oct 2, 2015 at 3:55 PM, Mathieu Malaterre <malat at debian.org> wrote:
> On Fri, Oct 2, 2015 at 2:12 PM, Emilio Pozuelo Monfort <pochu at 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
[...]



More information about the Debian-med-packaging mailing list