[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: soname number in name of dev-package?

Henning Makholm wrote:
Scripsit Jens Peter Secher <jps@debian.org>
But the advice in the library packaging guide is to do something like
	Package: libpackage2-dev
	Provides: libpackage-dev
	Conflicts: libpackage-dev
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 most cases.

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
    Package: libpackage-dev
    Provides: libpackage2-dev
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.


Reply to: