[arch-general] signoff kernel26-2.6.24.3-6

[Attila]

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.

> 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