Am 16.03.2010 18:47, schrieb W. Martin Borgert:
Quoting "Patrick Matthäi" <[email protected]>:
Splitting the package again would be too bloated in my opinion in this
case.
Another option would be just to recommend GTK+ and Qt instead
of depending on them. This way both GTK+ and Qt get installed
by default (or the package is on the machine anyway), but
nervous people like me could install w/o Qt (or GTK+).
Only recommending on the libraries is a bug, if mlt binary depends on it.
Most people I know with a KDE/GNOME desktop also have got some
applications depending on the over evil side, installed.
I have GNOME on most machines w/o Qt installed, but maybe
that's just me. I assume, that at least some XFCE and LXDE users
would prefer an option without 33 meg Qt dependency, however.
Yeah sure, there are people out in the world, who realy have got such
setups, but I think most people have got a mix.
Note, that in similar cases Debian does such splits, e.g.
http://packages.debian.org/changelogs/pool/main/v/virtualbox-ose/current/changelog#versionversion2.2.0-dfsg-1
or in some cases when complete RDBMSes or texlive gets pulled.
I am also a splitting fan, but not in this case. virtualbox e.g. is
useful on servers, where no X11 is installed. mlt is a bit useless
without a GUI.
There is also no problem with gtk and qt coexisting on the same pc and
the only both reverse dependencies of it are:
- kdenlive (kdelibs and qt)
- openshoot (gtk)
So if you decide to install one of them, you also would pull gtk or qt
on your pc..
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: [email protected]
[email protected]
Comment:
Always if we think we are right,
we were maybe wrong.
*/
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
