On Tue, 2009-12-01 at 23:51 +0100, Arvid Picciani wrote:
Aaron Griffin wrote:
Which package has patches to add these features? Looking at xorg-server, I only see one extraneous patch that simple replaces the default grey stipple pattern with black. The rest seem (at a glance) to fix real bugs
You have a point here, in that i have used a fuzzy description of the problem, in the assumption you and possible other readers remember the numerous rants on this ML. At very least I'd except You to remember your own blog. I'm going to post some hard facts to your convenience.
aep@andariel: ~ egrep 'enable|disable|patch -N' /var/abs/extra/xorg-server/PKGBUILD | wc -l 24
Jan has always done a good job in the past of keeping Xorg as impartial as possible without breaking things, and I'm assuming he did the same here.
i was about to state that i didnt target him at all. Then i ran this:
aep@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1); do egrep "enable|disable|patch -N" $i; done) | wc -l 543
Now you're propably saying numbers of downstream decisions doesn't say anything. Very true, which is why i prefer arguing about "intent"
aep@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot <jgc@archlinux.org>
and "bias"
So, just because I'm the maintainer of a package that is required for a lot of the packages I maintain makes me biased. Now, first of all: most of the patches that I apply are from upstream git/svn, or come from upstream bugtrackers fixing accepted bugs. Then about the dbus dependency in xorg: we do specifically enable config-dbus, but dbus is a dependency anyways: AC_ARG_ENABLE(config-hal, AS_HELP_STRING([--disable-config-hal], [Build HAL support (default: auto)]), [CONFIG_HAL=$enableval], [CONFIG_HAL=auto]) So, having hal installed on your system means vanilla hal autoconfiguration in xorg-server. As for the other --disable and --enable flags: most of them are default or autodetected. In some cases we don't want something and --disable it, in some other cases we want these things enabled so we --enable them. Flaming based on the count of --enable/--disable flags and the amount of applied patches does not help anything, and it doesn't improve a distribution or discussion either.
aep@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1 | cut -d '/' -f 5); do if (pacman -Si $i | grep gnome
/dev/null); then echo $i; fi; done) | wc -l 149
Ooh, so I'm the GNOME maintainer, what next?
The point is, just because *I* prefer something one way doesn't mean it's a good decision at the distro level.
So there is the name of some guy, who approves the unix philosophy, on this distro, but that guy decides it's a good idea that people who prefer ubuntu make the vital decisions.
I claim, You are leading a project whichs developers mainly disprove what You stand for, or claim to stand for. Which is why, ...
I never even installed Ubuntu on any system, how can I prefer it? Arch has thousands of packages that need to work together, sometimes you can't stick to your so called "unix philosophy".