Re: soname number in name of dev-package?
Henning Makholm wrote:
Scripsit Jens Peter Secher <email@example.com>
But the advice in the library packaging guide is to do something like
If the source-level API differs, then having libpackage2-dev will
allow other packages to Build-Depend on the API they are written
The key point isn't that the API differs, it's that it's not backwards
compatible. If it were backwards compatible, a (>= ...) versioned
dependency would handle things perfectly.
Note that that's the same rule as for renaming any other package: don't
do it unless the new version doesn't
The other issue is that it's not really particularly wise to treat
Build-Depends: as a formal specification of the build requirements in
Of course this is especially relevant when the API change can
make things break silently, but even outside that case, an explicit
build-dependency is easier to diagnose (and/or search for mechanically
over all packages in testing, say) than sudden compiler failures.
This is because in doing so, you're making a tradeoff between catching
potential silent breakage automatically, versus having packages rebuild
automatically without further effort. The common case is usually that
packages don't silently break; which makes all the extra effort in
manually updating packages something of a waste of time.
One _might_ do
but I think offhand that having the distinction in the real package
name will be easier on apt and buildds.
There seems to be a lot of unnecessary FUD (in the literal, not
pejorative sense) about how our dependency system works these days.
AFAIK apt and buildds handle virtual packages fine, though there are
some caveats if you do particularly crazy stuff.
Note that not changing the Package: name also means you don't have to
stress about Conflicts:/Provides:/Replaces: and ensuring users won't be
left with the old package indefinitely.