Re: Another rant on arch way abuse and false promises

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



Am Wed, 02 Dec 2009 09:13:59 +0100
schrieb Arvid Picciani <aep@xxxxxxxx>:

> please comment on: http://bugs.archlinux.org/task/17346
> 
> summary:
> 
> 1) I suggested reverting the dbus configure
>     flag to upstream default.
> 
> 2) Jan de Groot closed the bug with WONTFIX
>     since this revert WILL break
>     some third party gui configure util.

Especially this bug is pretty the same as the question I asked some
days ago about moving smbclient from depends to optdepends in various
packages like mplayer.

KISS doesn't mean minimalist, KISS means simple. Arch is a binary
distribution so if an upstream package has optional features which need
to be chosen at compile time then in most cases these features should
be compiled into this package by downstream. If a dependency can be
made optional at runtime then these dependencies are already put to
optdepends instead of depends so that the user can choose if he wants
them or not.

Regarding my mplayer/smbclient question it's obvious that I don't need
smbclient as I'm using a Linux only system. But there are at least some
people who need or want to use mplayer with samba. Because this
optional samba feature has to be compiled into mplayer - I didn't know
this when I asked this question - it's obvious that it's compiled into
mplayer.

With your wpa_supplicant example it's obvious that you don't need
networkmanager and therefore don't need its dbus support. But there are
a lot of people who need networkmanager and therefore the dbus support.
I on my own PC don't need networkmanager, too, but I'll soon install
Arch on another computer and there I'll need networkmanager. Because
the optional dbus support has to be compiled into wpa_supplicant it's
obvious that it is compiled in.

Forcing those people who need one or two features which are optional
but need to be chosen at compile time to rebuild these packages (would
be nearly every package) from ABS or AUR is not KISS and not the sense
of a binary distribution.

If you need a minimal instead of a simple system you should go for
Gentoo. There you have USE flags for every single optional feature of a
package and with those USE flags you can omit hal and dbus completely
from your system. But you should consider that in most cases you will
end in activating most of these optional features/USE flags because you
just need most of these optional features to get your system running or
at least to make it a bit more comfortable. See e.g. various media
players which have a USE flag for nearly every codec. But do you really
want a media player without MP3, Ogg/Vorbis or FLAC support? And it's
not so seldom on Gentoo that you get a message that you first need to
turn on a particular USE flag for a particular package and
reinstall/recompile this package before you can install the package you
actually want to install. This particularly happens with USE flags like
dbus and hal.

Including such USE flags into a binary distribution is just not
possible. There have been many such discussions before in the forums
and on the mailing lists. And the result of every such discussion was
that Arch is good as it is. And in my experience the decisions of the
downstream developers of Gentoo and of Arch are usually (not always)
deliberate if one thinks about it closer. On Gentoo there are from time
to time similar discussions, too, btw.

I on my own PC don't need networkmanager but I'll soon install Arch on
another computer and there I'll need networkmanager. If networkmanager
needs dbus to work then dbus is of course to be compiled into xorg in a
binary distribution and infact it does no harm. The same with my
mplayer smbclient example. If I wouldn't want smbclient I could compile
mplayer from ABS. But I switched from Gentoo to Arch because I want to
compile as few packages as possible. I just want a binary distribution
which gives nearly the same choice as Gentoo does but without
compiling. And this is what Arch does perfectly. If I only get this at
the price of having a handful dependencies installed which I don't need
and which costs only a few MB or KB on my harddisk then I'm absolutely
willing to pay this price because compiling the whole system as in
Gentoo takes too much time.

There is a second option regarding your dbus/wpa_supplicant example.
Why not file a bug report/feature request to upstream of networkmanager
to remove dbus from it? Of course you need to file this bug
report/feature request to upstream of every package which depends on
dbus. As soon as dbus is removed from every package or made optional at
runtime then you could reopen this bug report/feature request to Arch
again. Otherwise it's better to keep the optional dbus support in
wpa_supplicant.

So I'd suggest you to either compile the appropriate packages by
yourself from ABS or use Gentoo.

Btw., I, too, don't like hal and dbus much. But it's needed by many
packages and infact it doesn't hurt much.

Heiko


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux