Re: Library depending on -data packages
On Mon, 21 Mar 2011 at 17:18:00 +0100, Luca Capello wrote:
> When I found out about libm17n-0, I also found out that the change added
> a circular dependency and thus commented on this new bug why I think a
> library package should not depend on data packages
Which way to break the circular dependency needs to be considered case-by-case;
neither answer is universally right.
Sometimes the library (or executable) genuinely does need the data package -
substituting another data set in the same format wouldn't do what its users
expect. The data package typically just takes up space without doing anything
useful if you install it on its own, so it should have the
special::auto-inst-parts debtag and should usually Recommend the library or
executable.
For instance, openarena needs a corresponding version of openarena-data:
if you substitute a data-set in the same format (zipped Quake III-compatible
assets) with non-trivial modifications, it won't be network-compatible, and
might even crash if you don't make corresponding modifications to openarena.
The existence of openarena-data is an implementation detail of openarena,
so it has this relationship:
/--->--- Depends -->---\
openarena openarena-data
\---<-- Recommends --<--/
Looking at libraries, it seems libgnome2-0 has this relationship with
libgnome2-common.
Sometimes the library or executable can work without the data, but works better
with it (for instance, GLib isn't localized if its -data part is missing).
It recommends the data, and the data can optionally depend on the
library or executable:
/---<--- Depends --<---\
libglib2.0-0 libglib2.0-data
\--->-- Recommends -->--/
Sometimes the library or executable just needs *some* data in the right format:
it should typically Depend on, or even just Recommend, a virtual package
(with a preferred alternative). For instance, dictd can serve any compatible
dictionary or dictionaries of your choice.
S
Reply to: