[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why is help so hard to find?



On Sat January 15 2011 02:48:54 Neil Williams wrote:
> If the alternative software was maintained within Debian by an active
> team then maybe the switch could be a choice. If nobody steps up to do
> it, that choice is not available.


1. insserv

Legacy booting IS maintained in Debian.  The problem is that
sysv-rc.postinst contains an unwise recommendation to enable
insserv.

Enabling insserv is an irreversible step which can and does
cause damage and a serious waste of time.  It is not recoverable
even by restoring /etc without resort to undocumented magic.

Whether insserv actually breaks a particular server, or only
has the potential to do so, it is unwise to enable insserv
on any server as the actual or potential risks (hours or
days) far outweigh the actual or potential gains (seconds).

This is not to prevent people choosing to use insserv if they
wish.  This is not to prevent Debian from recommending that
people CONSIDER insserv.  But sysv-rc.postinst should not be
blinding recommending that people ENABLE insserv.

The fix is trivial, albeit any updated dialog will require
the attention of Debian's many hard-working translators.


2. KDE 3.5

Lenny has KDE 3.5.  KDE 3.5 is well-maintained upstream - by
Trinity now rather than KDE.  Many people prefer to use KDE
3.5 rather than KDE SC 4 - a radically different and far buggier
desktop with a similar name.

The problem is that KDE SC 4 has unnecessarily usurped the
KDE 3.5 package namespace.  This makes two things hard - upgrading
from Lenny to Squeeze+Trinity and maintaining KDE 3.5 within
Debian rather than outside.

This is not to prevent people from packaging and maintaining
KDE SC 4 if they so choose.  And this is not to prevent people
from choosing to install KDE SC 4 if they so choose.  Ideally
KDE 3.5 and KDE SC 4 would be co-installable (Trinity has
achieved this) but it is not essential.  What is important is
that KDE SC 4 not unnecessarily usurp the KDE 3.5 package
namespace and thereby make KDE 3.5 packaging and upgrades
unnecessarily difficult.


--Mike Bird


Reply to: