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.)
