ONE comment inserted below;
On Montag, 24. März 2008 22:47 RedShift wrote:
At first see this all only as the opionion of a normal user and i find it good that you challenge such things because this is even a good way to improve it.
If this discussion is only for devs than please apologize this and copy the lines below to /dev/null.-)
Lots of software is patched nowadays, even for very stupid things most of the old user base wouldn't have cared about. And when PKGBUILDs starts to grow to the point they need scrolling and comments to be clarified, that's just going the wrong way. (Hint, kernel26 PKGBUILD).
I do not like patches too. And yes, i love it that archlinux is using in the most cases the sources as they comes from the upstream. But sorry to say, the kernel is a special case.
If you find time take a look for the kernel source packages of another distributions and you will see that everyone is patching the kernel. Okay, what ist the reason for it? The kernel devs said in the past (sorry, i have no url) that getting the kernel stable is the job of the distributions teams. This is not fantastic and i don't like this situation too but this is the situation.
That is why i find that tpowa is doing a great job and the kernel26 PKGBUILD is a good example because all patches been commented so if you don't like it you can create very easy your own kernel package. And more than the half of the PKGBUILD is copying files and the reaons for it is that other packages need this include files.
Notice the large influx of new users. The fact alone that a topic has been started for a stable package repository *and people are willing to contribute to this*, shows the kind of users we're getting: the wrong ones. There has been an ongoing discussion on the bug tracker whether or not post uninstall scripts should stop daemons upon removal. These ideas come from users that are either inexperienced, or trying to mold Arch in something its not. And what about dependencies in initscripts... wtf? Any sane user can find them out for themselves and put them in the right order in rc.conf. What if someone doesn't want this behaviour? For example I don't want dbus and hal started, but what if the kdm rc.d script will do this for me? It ends up with a pretty big mess. Let alone the complexity that is added to the initscripts.
Smile, because i find that a kdm rc.d script is from my view unnecessary because you can handle it easy in the inittab file and this is the first time that i see that there is a kdm script.-) But i can understand that people who switch from another distribution will miss in the first moment some of this automatic things. Give them time and this "problem" will gone away but perhaps i see this too easy.
Coddling the user by just such an addition achieves nothing of either transient or of a lasting nature for a distro such as ours. i.e. *IF* this was the right way to go, then the other distros that are starting kdm via such a script wouldn't have people leaving their fold and switching to ArchLinux. Specifically, kdm, xdm, et al were ORIGINALLY started as part of the init processing string and/or X startup and specifically not part of a rc.d setup. The rc.d style of doing this for the various popular desktop managers was a later invention that came from the beginner's based distros. As for the rest of this discussion, as a LONG TIME user of ArchLinux I am finding it a good discussion to have at this point in time. Please keep the comments coming. I am greatly encouraged by you all having this discussion. Very best regards; Bob Finch
But adding largely untested and nobody-knows-where-it-came-from patches to the kernel is *evil*.
You be right that saying no is better than saying yes to everything but again the kernel is not such a good example as you think because the most is documented in the PKGBUILD.
What Arch needs is to have strict guidelines on PKGBUILDs and kick out any developers that don't have the same idea. A proposition:
Your suggestions sounds logical but they could demotivate too especially the part that users been lazy and you post this in the mailing group for users.
* Patches are unacceptable unless in the case the software wouldn't work *at all* (Hint, qt PKGBUILD)
Hmm, and who decides this? If this is decided by the maintainer of the package than you have the same situation as now or do i misunderstood something?
* Pre and post install/remove actions should be kept at a minimum. Assume the user is smart (quite the opposite of the current trend). Everybody can read the manpage to adduser and addgroup. Post install echos pointing out small hints to get going quickly is acceptable
Have you ever think about offering archlinux specific readmes as at example readme-udev-arch.txt at a central point for example /usr/share/doc/archlinux where the files have the same name as the package? Than from my view you don't need any hints in the pacman output.
* No branding or "Arch defaults". It only makes the PKGBUILDs more complex, and ruins the idea of the software coming in its original form from the authors
Strange because i have the impression that this happens in archlinux and the branding is on a minimal level.
Selecting your own theme is just a few mouse clicks away. Arch should never come with a fscked up KDE or Gnome profile like Ubuntu and others do. In fact, packages should *always* come with the defaults shipped by upstream.
Agree. I like it very much in archlinux that i have only to configure my desktop and not to find out how i can get away from the patched layout. On the other side i can understand that people loves kdemod but i prefer it too that such things should be in a separate repo and not in extra.
See you, Attila
Liviu Librescu - În veci pomenirea lui. (May his memory be eternal.)