2008/3/24, RedShift <redshift@pandora.be>: [skipped]
What Arch needs is to have strict guidelines on PKGBUILDs and kick out any developers that don't have the same idea. A proposition: * Patches are unacceptable unless in the case the software wouldn't work *at all* (Hint, qt PKGBUILD)
Disagree. *buggy* software needs patches too, and also "wouldn't work *at all*" is different depending on configurations (Hint: xorg) (yes, there is a chance to broke something else, so this should be done carefully) IMO patches for better hardware support are not bad if unintrusive. It's ok that people have different opinions on this.
* 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
Agree. Please report bugreports for those packages that you think should be improved, because it's hard to track them down and fix all in one step.
* Stress the fact that users must read pacman's output and the news. Alot of problems on IRC are related to the fact that people are lazy and don't read pacman's output _at all_. That's their own damn fault
Agree completely.
* No handholding (like, no automatic stopping of daemons upon pre remove, adding of groups, etc...)
The feature request for autostopping daemons was denied AFAIR, if some packages do this - please file a bugreport.
* Bugs and other issues that come from upstream, _should be fixed upstream_. If people do have problems with a certain issue, they can abs and makepkg themselves. (See rule 1)
(Dis)agree partially. Then 95% of users will have to fix a lot of upstream bugs on every major kernel/udev/dbus/xorg/etc. upgrade. I see it as a plus to save people's time for more interesting things by fixing those issues in one place (official packages). However, things like "OMG! Pidgin's tray icon is disappearing in some situations. Please fix ASAP!" should be sent to upstream by users, and those reports should (and actually are) closed as "Won't fix".
* 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
This was discussed in past. IIRC it was decided to do some branding while trying to make it optional (separate addon packages where possible). (and I feel OK with that) Things are still inconsistent though and I cannot say I am happy with the inconsistency.
Another point of interest may be that many people used to find gnome coming "ugly" by default (I don't know if this still the case). So what?
Ugly? I never hear that, but people's tastes are so different... I actually find it looking pretty nice. So I totally agree with "So what?" here. :-)
But when you have a kernel26 PKGBUILD that's 320 lines long, that simplicity is gone.
It's fun that the kernel is the most often questioned part, and not, say, xorg-server which have tons of patches too, but I haven't heard complaints about it. -- Roman Kyrylych (Роман Кирилич)