Scripsit Jens Peter Secher <[EMAIL PROTECTED]>But the advice in the library packaging guide is to do something like Package: libpackage2-dev Provides: libpackage-dev Conflicts: libpackage-devIf the source-level API differs, then having libpackage2-dev will allow other packages to Build-Depend on the API they are written against.
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.
Cheers, aj
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
