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.
> So if you really want to follow this approach, better do it the other way
> round.
> I.e make the package libdcmtk-dev and Provide libdcmtkN-dev.
>
> It's just useless and more work for everyone to be renaming the -dev package
> because they are not going to co-exist as long as you don't rename the src
> package as well.
Since I do not share your understand of `serious` issue here. I'll
leave it up to you to decide for the following packages:
- src:igraph
- src:vtk-dicom
