Re: Library depending on -data packages
(dropped cc's; hopefully that's okay.)
Hi!
Luca Capello wrote:
> I see these situations as a misuse of Depends: where Recommends: would
> be perfectly fine, otherwise Recommends: are useless. But given that it
> seems no one agrees with me, is such a behavior documented somewhere?
Checking policy, I see:
The Recommends field should list packages that would be found
together with this one in all but unusual installations.
which I grant is not all that helpful. The example I was introduced
to Recommends with is ancient: old X server packages used Recommends
to pull in a font server, because it was possible that your font
server might be running remotely but in all but unusual installations
you want a local one. (Of course nowadays the X server always has a
built-in font server.)
One use of Recommends I agree with is that most latex packages use
Recommends for their documentation (which _has_ to be part of the
default installation according to the license).
So let's just consider your examples. :)
emacs depends on m17n-db
------------------------
Bug#599643 is about what relationship m17n-lib has to m17n-db. Please
correct me if I'm wrong.
. libm17n provides an API for complex text layout
. m17n-db provides the actual complex layout rules
So, one might conclude, for libm17n to behave as advertised, one *has*
to have m17n-db installed. The DB is just an implementation detail
and could be provided just as well with internal tables in the library.
Wait, wait! But emacs depends on libm17n for complex text layout and
some people are just not going to care. What to do?
Option A. Split the functionality of libm17n-0 into two packages:
(1) libm17n-0-lib, which ensures binaries linked to libm17n-0 can at
least start up correctly and (2) libm17n-0, a dependency package
which depends on libm17n-0-lib and m17n-db and represents the actual
functionality. Change emacs to "Depends: libm17n-0-lib" and
"Suggests: libm17n-0". Make sure the behavior when m17n-db is not
installed is reasonable enough to function ok and to give a hint
that the end-user about what package to ask the sysadmin to install
to get full functionality.
Option B. Make emacs Suggests: and dlopen libm17n, and similarly
make sure the fallback behavior is okay.
Neither involves a Recommends. In either case some basic "task"
package probably ought to Recommends: m17n-db.
Many desktop apps depend on libatk1.0-data
------------------------------------------
Bug#599666 is about what relationship libatk has to libatk-data. Again,
please feel free to correct me if I go wrong.
libatk1.0-data contains soname-independent files which the runtime
libraries need. It consists mostly of locales and is a lot bigger
than the lib itself --- but that does not seem so unusual to me.
Hopefully some day we will find a better way to detail with
localization packaging to avoid wasting so much space.
emacs depends on anthy-common
-----------------------------
Bug#582797 is about dependencies on libm17n implying a much heavier
dependency (anthy) whose functionality is not widely used that way.
The complication (again, as I understand it) is that to demote the
dependency to a Suggests would require finding a good fallback
behavior when it is missing. According to that bug log, libm17n
upstream is working on it.
The plan is for the anthy input module to be in another package that
Depends: libanthy0, if I understand correctly. That input module
could Enhances: libm17n or libm17n could Suggests it.
Hope that helps,
Jonathan
Reply to: