[arch-general] signoff kernel26-2.6.24.3-6

[w9ya at qrparci.net]

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