Bug#252194: libgnomevfs2-common has too many Depends that should
be Suggests
Jakob Bohm
Jakob Bohm <jbj@image.dk>, 252194@bugs.debian.org
Mon, 7 Jun 2004 00:59:06 +0200
On Wed, Jun 02, 2004 at 11:21:22AM +0200, Josselin Mouette wrote:
> Le mer 02/06/2004 =E0 02:41, Jakob Bohm a =E9crit :
> > In addition to filling up the users disk space, some of those
> > directly or indirectly Depended on packages are or include
> > network daemons, I noticed fam and Kerberos, but there may be
> > others.
>=20
> This is not true. Only the fam and kerberos *libraries* are depended
> upon, you are not forced to install a fam daemon and a kerberos daemon.
libgnomevfs2-common Depends libfam0c102
libfam0c102 Recommends fam
[note that both dselect and aptitude default to
installing Recommends.]
=20
libgnomevfs2-common Depends libsmbclient
libsmbclient implements a quite notorious network protocol
libsmbclient Depends libkrb53
libkrb53 implements a complex, password-transmitting network
protocol needed only by some SMB client scenarios.
libkrb53 Suggests krb5-user (more krb programs)
=20
While only the "client" half of the SMB and Kerberos protocols
get installed, these protocols have sufficiently often been
the point of attack in security incidents, that many users
will not want them installed.
Some well-known attacks against the SMB and Kerberos protocols
are attacks against the client side, typically involving
server spoofing and fooling the client code into sending
passwords or otherwise trust the wrong server in
inappropriate ways.
And those were just the two cases that involved network
security.
I just spent the better part of Sunday trying to draw up a
detailed dependency graph of all the stuff brought in by the new
libgnomevfs2 packages. I didn't even manage to do 25% before
nightfall, it was so huge.
The core of the problem is this:
1. libgnomevfs2-dev is a development package for a commonly
used library, which means that it often needs to be
installed by buildds and by anyone working on any related
or unrelated aspect of any package linked against it.
This implies that the dependency closure of this package
should be kept as small and lean as technically feasible,
even the old version of the package brought in a lot, but
the new one is even worse.
2. libgnomevfs2 is a plugin system. The whole point of
having a plugin system is to allow users to add or remove
plugin functionality without recompiling. But the new
libgnomevfs2 packages completely takes away the users
freedom to do any such thing, by putting all the plugins in
the Depend-level core packages.
The previous version of the packages at least gave the
user one optional choice: Install the -extra package or
not. But this is still not any user or freedom oriented
way of packaging a plugin interface.
It would be extremely useful if the various gnomevfs2 plugins
were placed in one package each, and libgnomevfs2-common only
Suggest those. For transition, libgnomevfs2-extra could be a
meta-package Depending on those and Suggested by -common.
A less ideal solution would be to keep the plugins in one
package, but only Suggest the things they need, then make sure
libgnomevfs2 using apps still run with those other packages
absent. (Depending on how libgnomevfs2.so uses dlopen() etc.,
this may or may not be trivial).
In the hope of an ever better system
J.
P.S.
Nice ASCII Swirl...
--=20
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.