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.
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.
Cheers,
Emilio
