Re: [arch-general] signoff kernel26-2.6.24.3-6
Simo Leone wrote:
On Mon, Mar 24, 2008 at 07:28:13PM +0100, Tobias Powalowski wrote:
Users are happy with the new ISOs, just read the Forum thread about it.
You know what. I don't care if the users are happy with the new ISOs. That's right, I finally said it. _I DON'T CARE_
I don't care because _I_ am not happy with them. As someone who can see that from a technological standpoint, it's a marvel that they even work, that is, as a software developer, I'm ashamed to be associated with such a shoddy product.
I've offered alternatives, hell I've spent a lot of time offering alternatives, built on more solid software enginerring principles than "Users are Happy", but no one around here, save Dan and Aaron, who just happen to be code contributors, seems to give a damn. What's up with that?
*** Prelude *** This discussion was started when tpowa was asking for a signoff on the kernel26 package, which includes patches for an out-of-tree kernel module for a certain wireless card. *** What Dan McGee said *** I have an Eee, I managed to pull off an FTP install just fine. I compiled the driver by hand, just as has always been the case for out-of-tree driver with Arch if there is not already a separate package for it. I did this 22 months ago for my zd1211 wireless stick before it was in the mainline kernel, and I had *0 days of desktop linux experience* at that time (on my own machine). 0 days. And now we bend over backwards for someone needing a driver? Ugh. I thought April fools and the rename to Newb Linux wasn't for another week. -Dan *** My response *** I find myself in 100% agreement on Simo's and Dan's opinion. I've warned for this situation before (see the bug tracker). An example should be taken from CRUX, they've held true to their principles and said screw those who don't agree. And they're right, otherwise we're just on the road to the next Ubuntu. 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 wanted to steer clear of personal attacks but unfortunately, tpowa has been a large contributer to the "lets adapt to the community"-style. I'm sorry to say it, but that's how I experience it (because of his work on kernel26 and qt) - and it needs to be said! Arch used to be different. I wouldn't be very surprised if Judd raised eyebrows on what's been going on lately. 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. What Arch needs, is to say NO to things. There will always be users that disagree, can't use some package because it doesn't fit them. Especially the kernel, all these half-baked largely untested patches for things only a few people (or even just 1) use is a threat to the stability of the kernel package. I've had my share of hardware that didn't work for me, these issues are solved by either compiling your own kernel, replacing the hardware or simply waiting for the next kernel release. But adding largely untested and nobody-knows-where-it-came-from patches to the kernel is *evil*. Another example is the addition of the uucp group by default to /etc/groups. The number of users that use dailup and faxing is *so limited*. And they can just as well addgroup themselves. But meanwhile, all the other users have to take this uucp crap on a default install. And don't say they can groupdel afterwards, Arch is supposed to be slim BY DEFAULT. If people need to start removing crap after they've installed Arch, then something is definitely wrong. 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) * 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 * 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 * No handholding (like, no automatic stopping of daemons upon pre remove, adding of groups, etc...) * 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) * 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 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? 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. That being said, there's no such thing as one size fits all. There will *always* be users that "fall out of the boat" (a Dutch expression). But the fact is, because of Arch's simplicity, Arch can be made to work for these people in a very easy way. But when you have a kernel26 PKGBUILD that's 320 lines long, that simplicity is gone. The users should adapt to Arch, not the other way around. Glenn
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 (Роман Кирилич)
-----Oorspronkelijk bericht----- Van: arch-general-bounces@archlinux.org [mailto:arch-general- bounces@archlinux.org] Namens Roman Kyrylych Verzonden: dinsdag 25 maart 2008 9:48 Aan: General Discusson about Arch Linux Onderwerp: Re: [arch-general] signoff kernel26-2.6.24.3-6
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.
It's fun to see that from the mess that makes up 320 lines of PKGBUILD, almost half of it is copying of headerfiles to /usr/src. A package containing lots of lines doesn't mean it's a bad package, as long as they're documented. Since Tobias took over kernel26 maintenance and switched it to mkinitrd/initcpio/initramfs/whatever, I stopped compiling my own kernels, as the standard kernel contains everything I need. If there are objections against a kernel that works and includes support for as much as possible things, my opinion is to remove everything from the kernel, supply a minimal kernel with all default things not marked as experimental enabled and let each and every user build his own kernel. How funny will that be? As for xorg-server: it's funny you're brining that one up. One week ago, I looked through the patches applied by us and other distributions. Many of the included patches do stuff we don't support or use in arch, so they got removed. Why would we fix Xprint using 6 patches and run --disable-xprint in the configure step, why would we fix Xorg to run with an X86 emulator, etc. I was sick of all these patches in xorg-server. I removed tonnes of patches from the PKGBUILD, cleaned it up and put the left-over combined patchset in a tarball and uploaded it to FTP. My opinion is that patching is good, but please take a look for every patch if they're really needed. Just including random patches because other distributions include them too is bad. I don't think our xorg-server maintainer should take all blame here: upstream quality of xorg-server is very very very bad. There's no maintenance on the server-1.4 branch, and any maintenance done there is broken if you don't add a shitload of extra patches.
On Tue, Mar 25, 2008 at 10:16:51AM +0100, Jan de Groot wrote:
-----Oorspronkelijk bericht----- Van: arch-general-bounces@archlinux.org [mailto:arch-general- bounces@archlinux.org] Namens Roman Kyrylych Verzonden: dinsdag 25 maart 2008 9:48 Aan: General Discusson about Arch Linux Onderwerp: Re: [arch-general] signoff kernel26-2.6.24.3-6
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.
It's fun to see that from the mess that makes up 320 lines of PKGBUILD, almost half of it is copying of headerfiles to /usr/src. A package containing lots of lines doesn't mean it's a bad package, as long as they're documented. Since Tobias took over kernel26 maintenance and switched it to mkinitrd/initcpio/initramfs/whatever, I stopped compiling my own kernels, as the standard kernel contains everything I need. If there are objections against a kernel that works and includes support for as much as possible things, my opinion is to remove everything from the kernel, supply a minimal kernel with all default things not marked as experimental enabled and let each and every user build his own kernel. How funny will that be?
As for xorg-server: it's funny you're brining that one up. One week ago, I looked through the patches applied by us and other distributions. Many of the included patches do stuff we don't support or use in arch, so they got removed. Why would we fix Xprint using 6 patches and run --disable-xprint in the configure step, why would we fix Xorg to run with an X86 emulator, etc. I was sick of all these patches in xorg-server. I removed tonnes of patches from the PKGBUILD, cleaned it up and put the left-over combined patchset in a tarball and uploaded it to FTP. My opinion is that patching is good, but please take a look for every patch if they're really needed. Just including random patches because other distributions include them too is bad. I don't think our xorg-server maintainer should take all blame here: upstream quality of xorg-server is very very very bad. There's no maintenance on the server-1.4 branch, and any maintenance done there is broken if you don't add a shitload of extra patches.
Other distros applying more patches in compare to Archlinux is not entirely true. http://crux.nu/ports/crux-2.4/xorg/xorg-server/Pkgfile http://ftp.ntua.gr/pub/linux/slackware/slackware_source/x/x11/patch/xorg-ser... http://gentoo-portage.com/AJAX/Ebuild/59397/View Archlinux has much in common with 2 of the above distros, CRUX and Slackware. The first uses 1 patch and the second 3. I assume you have checked with distros like Debian and Fedora, after all its their patches we have in xorg-server most of the time.
On Tue, Mar 25, 2008 at 01:09:08PM +0200, Grigorios Bouzakis wrote:
On Tue, Mar 25, 2008 at 10:16:51AM +0100, Jan de Groot wrote:
-----Oorspronkelijk bericht----- Van: arch-general-bounces@archlinux.org [mailto:arch-general- bounces@archlinux.org] Namens Roman Kyrylych Verzonden: dinsdag 25 maart 2008 9:48 Aan: General Discusson about Arch Linux Onderwerp: Re: [arch-general] signoff kernel26-2.6.24.3-6
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.
It's fun to see that from the mess that makes up 320 lines of PKGBUILD, almost half of it is copying of headerfiles to /usr/src. A package containing lots of lines doesn't mean it's a bad package, as long as they're documented. Since Tobias took over kernel26 maintenance and switched it to mkinitrd/initcpio/initramfs/whatever, I stopped compiling my own kernels, as the standard kernel contains everything I need. If there are objections against a kernel that works and includes support for as much as possible things, my opinion is to remove everything from the kernel, supply a minimal kernel with all default things not marked as experimental enabled and let each and every user build his own kernel. How funny will that be?
As for xorg-server: it's funny you're brining that one up. One week ago, I looked through the patches applied by us and other distributions. Many of the included patches do stuff we don't support or use in arch, so they got removed. Why would we fix Xprint using 6 patches and run --disable-xprint in the configure step, why would we fix Xorg to run with an X86 emulator, etc. I was sick of all these patches in xorg-server. I removed tonnes of patches from the PKGBUILD, cleaned it up and put the left-over combined patchset in a tarball and uploaded it to FTP. My opinion is that patching is good, but please take a look for every patch if they're really needed. Just including random patches because other distributions include them too is bad. I don't think our xorg-server maintainer should take all blame here: upstream quality of xorg-server is very very very bad. There's no maintenance on the server-1.4 branch, and any maintenance done there is broken if you don't add a shitload of extra patches.
Other distros applying more patches in compare to Archlinux is not entirely true.
http://crux.nu/ports/crux-2.4/xorg/xorg-server/Pkgfile http://ftp.ntua.gr/pub/linux/slackware/slackware_source/x/x11/patch/xorg-ser... http://gentoo-portage.com/AJAX/Ebuild/59397/View
Archlinux has much in common with 2 of the above distros, CRUX and Slackware. The first uses 1 patch and the second 3. I assume you have checked with distros like Debian and Fedora, after all its their patches we have in xorg-server most of the time.
And by the way since the Slackware link is for xorg-server-1.3.0.0 heres the one for 1.4.0.90 http://ftp.ntua.gr/pub/linux/slackware/slackware-current/source/x/x11/patch/...
On Monday 24 March 2008 22:47:34 RedShift wrote:
I wanted to steer clear of personal attacks but unfortunately, tpowa has been a large contributer to the "lets adapt to the community"-style. I'm sorry to say it, but that's how I experience it (because of his work on kernel26 and qt) - and it needs to be said! Arch used to be different. I wouldn't be very surprised if Judd raised eyebrows on what's been going on lately.
imho somone should slap some arch devs around with "the arch way". multiple times. until they get it. I wish judd would suddenly appear and cast some magic spells to vanish all nonbelievers.
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)
yeah. Qt.... good example of how arch lost its way. Current list of distros we "reject" bug reports from (well we tell the users to try an upstream version): debian, gentoo, fedora, mandriva, archlinux. you made it on the list, congratulations.
* Pre and post install/remove actions should be kept at a minimum. Assume the user is smart (quite the opposite of the current trend). actually written down in the "arch way"
* 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 we used to kick those people out without any hesitation.
* No handholding (like, no automatic stopping of daemons upon pre remove, adding of groups, etc...) actually written down in "the arch way". and even phrakture agreed on irc.
* 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) actually written down in "the arch way".
* 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 actually written down in "the arch way".
i believe archlinux is lost and i stopped fighting for it. It's exhausting to fight against argumentation like "but other distros do the same". those people just didnt get the point and should be kicked out of arch directly. You argue that those people actually contribute too much to kick them out? Look. they just contribute things that we don't want. We don't want downstream patches. We don't want automatic scripts (except udev, it damn rocks, thanks for that). We don't want downstream split packages. You could safe hundrets of hours by just not doing that. No, no. the real issue is: Arch is going mainstream, and there are more people who aprechiate that then there are offenders. For those of you who adore the arch way, I suggest grabbing pacman and all the good stuff that arch had, and just go to slackware. We're currently evaluating slack for servers. I miss my good old pacman, but at least its not feeling like ubuntu. btw. concerning the ISOs: i never used them. they suck. pacman -r ftw -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
On Tue, Mar 25, 2008 at 08:07:04PM +0100, Arvid Ephraim Picciani wrote:
On Monday 24 March 2008 22:47:34 RedShift wrote:
I wanted to steer clear of personal attacks but unfortunately, tpowa has been a large contributer to the "lets adapt to the community"-style. I'm sorry to say it, but that's how I experience it (because of his work on kernel26 and qt) - and it needs to be said! Arch used to be different. I wouldn't be very surprised if Judd raised eyebrows on what's been going on lately.
imho somone should slap some arch devs around with "the arch way". multiple times. until they get it. I wish judd would suddenly appear and cast some magic spells to vanish all nonbelievers.
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)
yeah. Qt.... good example of how arch lost its way. Current list of distros we "reject" bug reports from (well we tell the users to try an upstream version): debian, gentoo, fedora, mandriva, archlinux. you made it on the list, congratulations.
* Pre and post install/remove actions should be kept at a minimum. Assume the user is smart (quite the opposite of the current trend). actually written down in the "arch way"
* 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 we used to kick those people out without any hesitation.
* No handholding (like, no automatic stopping of daemons upon pre remove, adding of groups, etc...) actually written down in "the arch way". and even phrakture agreed on irc.
* 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) actually written down in "the arch way".
* 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 actually written down in "the arch way".
i believe archlinux is lost and i stopped fighting for it. It's exhausting to fight against argumentation like "but other distros do the same". those people just didnt get the point and should be kicked out of arch directly. You argue that those people actually contribute too much to kick them out? Look. they just contribute things that we don't want. We don't want downstream patches. We don't want automatic scripts (except udev, it damn rocks, thanks for that). We don't want downstream split packages. You could safe hundrets of hours by just not doing that.
No, no. the real issue is: Arch is going mainstream, and there are more people who aprechiate that then there are offenders. For those of you who adore the arch way, I suggest grabbing pacman and all the good stuff that arch had, and just go to slackware. We're currently evaluating slack for servers. I miss my good old pacman, but at least its not feeling like ubuntu.
btw. concerning the ISOs: i never used them. they suck. pacman -r ftw -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
Well actually the Arch Way has change a lot recently. Wiki says it was done in order to be "more formal and understandable" but i feel quite the opposite. http://wiki.archlinux.org/index.php?title=The_Arch_Way&diff=32398&oldid=32300 Greg
On Tuesday 25 March 2008 20:32:01 Grigorios Bouzakis wrote:
Well actually the Arch Way has change a lot recently. Wiki says it was done in order to be "more formal and understandable" but i feel quite the opposite. http://wiki.archlinux.org/index.php?title=The_Arch_Way&diff=32398&oldid=323 00
Greg indeed. thanks alot for that link. That new version is a lot less technical, but i just figured its a lot closer to judds version: http://phraktured.net/arch-way.html In fact his version of the arch way doesn't address many of the issues we are facing. It's way to fuzzy to make policies out of it.
You can only _assume_ that with "Arch is not primarily concerned about the user." he means something like "rtfm or stfu", but he never says exactly that. He neither says that init script dependencies are rediculous and everyone suggesting that should be shot directly. he just says "It is better to be technically elegant with a higher learning curve, than to be easy to use, and technically crap.", and we _assume_ that he was refering to shooting. He _doesn't_ address downstream patching in any way. I'd say that "the arch way" as i know it (and propably most of you old timers), was created out of thin air, or from the fact that arch _used_ to be like that. It was a common assumption that archlinux will continue it forever, but you can't blame the devs for not following policies if there are none. I only have one simple demand: Position yourself. I want you to have a (public available) policy that either does support or disapprove the points glen (RedShift) brought up in his mail. Becouse i believe this not beeing clearly written down IS the issue. If you have such a page on archlinux.org you can always tell the loosing side of that discussion to stfu and go use a different distro, but you have to do it! You can't get both the newbies and the professional users. That doesn't fit. It's inconvenient to draw sharp lines, becouse you seperate people. And it's convenient, becouse you seperate people.
On Tue, Mar 25, 2008 at 2:07 PM, Arvid Ephraim Picciani <aep@ibcsolutions.de> wrote:
i believe archlinux is lost and i stopped fighting for it. It's exhausting to fight against argumentation like "but other distros do the same". those people just didnt get the point and should be kicked out of arch directly. You argue that those people actually contribute too much to kick them out? Look. they just contribute things that we don't want. We don't want downstream patches. We don't want automatic scripts (except udev, it damn rocks, thanks for that). We don't want downstream split packages. You could safe hundrets of hours by just not doing that.
I am a strong believer that this entire paragraph was constructed by typing "win" over and over.
On Wednesday 26 March 2008 00:37:02 Aaron Griffin wrote:
I am a strong believer that this entire paragraph was constructed by typing "win" over and over. gosh, how did you figure? meh. mind adding something actually usefull? -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
On Tue, Mar 25, 2008 at 7:05 PM, Arvid Ephraim Picciani <aep@ibcsolutions.de> wrote:
On Wednesday 26 March 2008 00:37:02 Aaron Griffin wrote:
I am a strong believer that this entire paragraph was constructed by typing "win" over and over. gosh, how did you figure? meh. mind adding something actually usefull?
Er? If you took that as bad, it wasn't meant that way. It was an internet-ism. "This X is made of win and awesome". It was my informal way of saying "I agree 100%". I could add more, but we (devland) are having a very similar internal discussion on our private list. Suffice to say: for all the "old timers" out there, I am on your side. I *am* an "old timer", and I will do everything in my power to make arch what it was. - Aaron Griffin
On Wednesday 26 March 2008 01:21:26 Aaron Griffin wrote:
gosh, how did you figure? meh. mind adding something actually usefull?
Er? If you took that as bad, it wasn't meant that way. It was an internet-ism. "This X is made of win and awesome". It was my informal way of saying "I agree 100%". i'm sory. totally my bad. i was thinking of the term in business language. you say "screaming win win over and over again" when you refer to somone just repeating common buzzword templates for social networking. never mind.
I could add more, but we (devland) are having a very similar internal discussion on our private list. right. i'll stfu and wait. please inform the public about the outcomming.
Suffice to say: for all the "old timers" out there, I am on your side. I *am* an "old timer", and I will do everything in my power to make arch what it was. Sounds very promising. Thank you! - Aaron Griffin
-- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
I feel the need to express my position for a variety of reasons, the most prominent being I am the one who proposed the discussion about the automatic service stopping before uninstalling. Let me state this again: I proposed the *discussion* about it, since there was no official guideline. I never asked to implement it, even though at that time I saw it as a defect. My opinion has changed since then. As a TU I take my work very seriously and I feel responsible for my own decisions. This is the reason why I prefer to ask when there's no official policy, and the above case demonstrated it is a good practice. I often don't take into account a variety of factors which later show up to be fundamental, that's why when I come up with proposals that sound like "handholding", "un-archish" or just plain ugly I ask devs, TUs and the community what they think about them. I am still learning and I need their experience. Please take my proposals and questions as an effort to follow the Arch Way, and not as an attempt to change it. On Wed, Mar 26, 2008 at 1:21 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Suffice to say: for all the "old timers" out there, I am on your side. I *am* an "old timer", and I will do everything in my power to make arch what it was.
Do 3+ years of Arch make me an "old timer"? I think so. Count me on that list. Corrado
On Tue, 25 Mar 2008 19:21:26 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote: <snip>
Suffice to say: for all the "old timers" out there, I am on your side. I *am* an "old timer", and I will do everything in my power to make arch what it was.
I switched to Arch last September, from Slackware, precisely because of what I had learned about Arch "as it was". I am not a fanatical purist, or even a computer science person. I am just a reasonably well-informed ordinary user who hates to be babied. I can only say that I *very* much hope that and your allies you win the battle Aaron. Geoff
Geoff wrote:
On Tue, 25 Mar 2008 19:21:26 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
<snip>
Suffice to say: for all the "old timers" out there, I am on your side. I *am* an "old timer", and I will do everything in my power to make arch what it was.
I switched to Arch last September, from Slackware, precisely because of what I had learned about Arch "as it was". I am not a fanatical purist, or even a computer science person. I am just a reasonably well-informed ordinary user who hates to be babied. I can only say that I *very* much hope that and your allies you win the battle Aaron.
Geoff
I think all things considered a balance must always be kept between 'power' and 'ease of use' no one wants an OS that is too complicated to keep up, nor as one of you said to feel 'babied' by it either. I have seen a few changes in Arch throughout the years and most of them, for my part, have been moving towards a positive such as the way Pacman includes mirrors and the mirror-list files. However if someone is really peeved about the direction that Arch has begun to take they might always fork the distro at the last version that was suitable to them - comment out some problematic pacman mirrors ;) and take a more 'sourced' approach to the issues they see.
On Wed, 26 Mar 2008 17:43:14 -0700 Justin Gx <justingx2@gmail.com> wrote: <snip>
However if someone is really peeved about the direction that Arch has begun to take they might always fork the distro at the last version that was suitable to them - comment out some problematic pacman mirrors ;) and take a more 'sourced' approach to the issues they see.
I apologise for talking too much in this thread. I don't have the seniority for people to be much interested my views. Still .. Justin, the problem with your suggestion (which in some more or less subtle form inevitably crops up in discussions of this kind), is its presupposition that "the direction that Arch has begun to take" is predestined to continue. It assumes that there has been a debate (or perhaps that no debate was possible in the first place), and has been lost - so that dissenters are howling at the moon. I do not understand this to be the case here. So far as I can tell, a debate is taking place to which users can contribute (no doubt minimally), by expressing their views. Isn't that what a general mailing list on an open source project is for? Isn't that better than walking (forking) away? Geoff
It assumes that there has been a debate (or perhaps that no debate was possible in the first place), and has been lost
On Wednesday 26 March 2008 23:10:58 Geoff wrote: there was on irc. its where i felt pretty alone with my ideas. left freenode. turns out that the medium irc is missing a majority of voices. -- On Wednesday 26 March 2008 20:21:49 Dimitrios Apostolou wrote:
If arch returns to "the arch way" please remind me to post a list of packages with superfluous patches applied... I have a few very specific packages in mind too :) I even though about picking a specific package up in case the specific developer gets accidently hit by a car multiple times or lost in a snake pit during the process. -- On Wed 2008-03-26 16:46 , Jan de Groot wrote: I think we are overrating the problem here. I never saw in Arch's packages patches applied just for fun, or to add useless features [..] I have no idea why mactel patches aren't merged in the vanilla tree, but I'd like to boot Arch on my macbook anyway. [..] if someone wants a kernel26-zomgvanillaistehbest , he can remove all the patches and create the packages by himself. I disagree, but it doesn't matter since no one forces us to use the same distro. I chose arch becouse its ideas match MINE. not yours. --
On Wed, Mar 26, 2008 at 3:04 PM, Filip Wojciechowski <fwojciec@gmail.com> wrote:
I, personally, find this divisive rhetoric of good (old) users vs. bad (new) users, as well as good developers (who do what "we" want them to do) vs. bad developers (who "should be kicked out") rather disturbing :/
well face it. there are two different tastes here. see above. It's not "new" vs "old" but actually arch way vs not. Finally lines have to be drawn clearly. It's unconvinient becouse it _might_ result in some people leaving archlinux. but it doesnt have to. Althought actually i expect a couple of users to leave: Those who cry in irc about not getting into a ready fucked up kde or gnome right after clicking throught the gui installer. -- On Wednesday 26 March 2008 16:46:18 Jan de Groot wrote:
Get ready to run a distro that breaks your system on every pacman -Syu because upgrade paths are not handled. Yes, this is win win win I guess. You are totally right. Archlinux with the full force of the arch way, has a higher risk to fail on system upgrade then debian. But: (Without going into detail how debians "convenience "automaticly crippled my apache a few weeks ago):
I am willing to trade stability for transparency. I am willing to trade safety for freedom. quote me on that if you need to. This view hasnt changed since i am alive. I can use my damn brain and i don't need other people to do that for me.
If we want to go this way, I consider myself as ex-developer.
Thats sad. But i dont blame you devs (except one, who i blame personally for beeing an asshole and for knowingly damaging specific projects including arch). It's just that arch isnt a 100 users distro anymore, so you see yourself actually providing more tools for more users. etc. It's understandable that you feel uncomfortable about rejecting a specific patch just becouse it violates the arch way while it could help like 20 users get arch run by default on their dishing machine. And of course you have to admit that you like getting attention from users who admire your work for them. Most of us who are now complaining propably never did say thank you for fixing a stupid typo in some stupid Makefile, becouse we can do that ourselfs. But: i do say thank you for all those years of having a working distro that actually didn't make me want to punch faces every keystroke i make. I admire your work no less. In fact my admiration is of higher quality, becouse i actually mean it, and i actually stand here (virtually. imagine me in a ninja suite) and fight for it. -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
2005/3/27, Arvid Ephraim Picciani <aep@ibcsolutions.de>:
I am willing to trade safety for freedom.
LOL, who took your freedom? 2005/3/27, Arvid Ephraim Picciani <aep@ibcsolutions.de>:
On Wednesday 26 March 2008 16:46:18 Jan de Groot wrote:
If we want to go this way, I consider myself as ex-developer.
Thats sad. But i dont blame you devs (except one, who i blame personally for beeing an asshole and for knowingly damaging specific projects including arch). . . . But: i do say thank you for all those years of having a working distro that actually didn't make me want to punch faces every keystroke i make.
I believe Jan have not quit yet, the key word is "if". Can we please stop flaming in this thread? -- Roman Kyrylych (Роман Кирилич)
On Thursday 27 March 2008 08:40:10 Roman Kyrylych wrote:
Can we please stop flaming in this thread? Didn't mean to. Sorry if my choosing of words makes it look like a flame. That's just my way of expressing things and no reason to not take me serious.
-- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
I know I am perhaps a bit late to this thread and perhaps don't belong here but I'd like to weigh in. Here's some history if anyone cares: I've been an Arch user since 0.6 and spent 6-8 months in 2004/2005 being probably the most active person in #archlinux when I helped more new users than I can count. I've since been preoccupied by my studies but I continue to use Arch whenever I can and keep it as my go-to distro for things ranging from small installs to desktop systems I intend to heavily use. I like Ubuntu, I like Fedora, I like Slackware, I used to like Gentoo and I keep up with their releases and try all of them, but Arch is my hands down favorite. I moved to Arch because it was such a clean distrobution which you could always figure out and keep track of, and thats why I've kept up with it. If anything, I'm the user you might not be hearing from. I think the best example I've seen of the "Arch Way" is the refusal of making pacman run lilo after it had installed a new kernel. Arch expects the user to understand their system, understand what they need, and be very clear and simple in what it does. I'd like pacman to give me output when it updates a package whose path, config syntax or whatever changed so I can be responsible for fixing it. I don't want the installer to be making groups for me, I don't want the package manager to be changing any more than it really needs to. As for bug fixes, in my opinion, I feel its up to the pacackage mainters, sometimes things just come up that need fixing and can't be bothered with waiting for upstream. However, Arch should stay out of the way enough that I can submit a bug report to a project and KNOW exactly what I may have that might effect the apps behavior because I installed or changed something to run significantly different from upstream. I agree with most of the old timers here, if you guys want a distro that holds your hand through everything and tells you everything, then perhaps Arch isn't for you, the Frugalware guys are nice though! Arch has always expected their users to be *smart* and have a solid understanding of their system and their setup and leave running the system up to the user. Thats what gentoo used to be in 2003/2004; when it became swamped with new users who turned it into the automated and out-of-control distro it is today, I (and many others) promptly dropped it and went back to Slack. Please, don't send Arch into the hole of being a distro so automated it escapes the control of the user from the start and never relenquishes it. Thank you, sepht P.S. Sorry for the formatting, I dunno what Opera+gmail are up to...
2008/3/26, Aaron Griffin <aaronmgriffin@gmail.com>:
Suffice to say: for all the "old timers" out there, I am on your side. I *am* an "old timer", and I will do everything in my power to make arch what it was.
You're my hero. :-) Count me too on that list. -- Giovanni Scafora Arch Linux Trusted User (voidnull) http://www.archlinux.org linuxmania@gmail.com
On Tue, Mar 25, 2008 at 7:21 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Suffice to say: for all the "old timers" out there, I am on your side. I *am* an "old timer", and I will do everything in my power to make arch what it was.
I switched to arch only recently, but I've been using linux 10+ years. So, as far as linux goes, I *am* an "old timer" as well, and as others have stated do not wish to be babied and I need to know exactly what is going with service starting/stopping, etc, and be able to control it myself. I switched to arch from ubuntu (after trying half a dozen or so other distros in between) and do not want arch to become an ubuntu clone with only a different but similar package manager.
Arch should be careful not to go the same way Gentoo did. (Of course Arch and Gentoo are two different concepts). Gentoo at the beginning was quite purist and you had do have "some *NIX intelligence" to use it. You had to know how the start up worked and how the kernel is called by grub, if you didn't know you learnt if. Just a few examples. You have to distinguish between high level Linuxes like Ubuntu and low level Linuxes like www.linuxfromscratch.org. Gentoo moved from low level to high level and lost many good people because of this, maybe it gained some too. Arch has to decide where it stands. Do everything for the user or have a good documentation system where stuff is explained, if the user wants to do something. Personally I use Arch because I can tell it what to do and if I don't tell it to do something, it will not do it. So if I want automount I enable it, otherwise I don't want it. Cheers Didi ---- www.cern.ch/ribalba / www.ribalba.de Email / Jabber: ribalba@gmail.com Phone (Work) : +41 22 7679376 Skype : ribalba Address : CERN / IT-FIO-FS / GENEVE 23/ SCHWEIZ
2008/3/26, Dwight Schauer <dschauer@gmail.com>:
On Tue, Mar 25, 2008 at 7:21 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Suffice to say: for all the "old timers" out there, I am on your side. I *am* an "old timer", and I will do everything in my power to make arch what it was.
I switched to arch only recently, but I've been using linux 10+ years. So, as far as linux goes, I *am* an "old timer" as well, and as others have stated do not wish to be babied and I need to know exactly what is going with service starting/stopping, etc, and be able to control it myself. I switched to arch from ubuntu (after trying half a dozen or so other distros in between) and do not want arch to become an ubuntu clone with only a different but similar package manager.
Hey, please everyone don't be scared about Arch becoming an Ubuntu clone, issues that devs are discussing recently are *far* from that, so do not oversize the situation please. Don't Panic! ;-) -- Roman Kyrylych (Роман Кирилич)
On Wed, Mar 26, 2008 at 9:47 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote: [snip]
Hey, please everyone don't be scared about Arch becoming an Ubuntu clone, issues that devs are discussing recently are *far* from that, so do not oversize the situation please. Don't Panic! ;-)
-- Roman Kyrylych (Роман Кирилич)
Also... I, personally, find this divisive rhetoric of good (old) users vs. bad (new) users, as well as good developers (who do what "we" want them to do) vs. bad developers (who "should be kicked out") rather disturbing :/ Filip
On Wed, 26 Mar 2008 10:04:45 -0400
I, personally, find this divisive rhetoric of good (old) users vs. bad (new) users, as well as good developers (who do what "we" want them to do) vs. bad developers (who "should be kicked out") rather disturbing :/
I am sure that nobody wants to demonise *any* of the hard-working devs. On the other hand, there is no point in people hiding the strength of their opinions on such an important point of principle. We should hate the sin, not the sinner. Geoff
On Wed, Mar 26, 2008 at 3:04 PM, Filip Wojciechowski <fwojciec@gmail.com> wrote:
I, personally, find this divisive rhetoric of good (old) users vs. bad (new) users, as well as good developers (who do what "we" want them to do) vs. bad developers (who "should be kicked out") rather disturbing :/
I (we?) didn't mean to pass this message. Users choose their favorite distro, not the other way round. Those who we call "old timers" aren't better than new users in any way. New people are always welcome in the community, they just shouldn't think Arch will become more user friendly (as Ubuntu-like distros say) only because more people uses it. In fact Arch has always been about control and lightness, and personally I will use it until it stays this way. If this point is clear, I think the conversation is closed :-) Corrado
-------- Original Message -------- Subject: Re:[arch-general] signoff kernel26-2.6.24.3-6 From: Dwight Schauer <dschauer@gmail.com> To: General Discusson about Arch Linux <arch-general@archlinux.org> Date: mer 26 mar 2008 14:13:42 CET
On Tue, Mar 25, 2008 at 7:21 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Suffice to say: for all the "old timers" out there, I am on your side. I *am* an "old timer", and I will do everything in my power to make arch what it was.
I switched to arch only recently, but I've been using linux 10+ years. So, as far as linux goes, I *am* an "old timer" as well, and as others have stated do not wish to be babied and I need to know exactly what is going with service starting/stopping, etc, and be able to control it myself. I switched to arch from ubuntu (after trying half a dozen or so other distros in between) and do not want arch to become an ubuntu clone with only a different but similar package manager.
Hi, exact same for me. "old timer", don't want to be babied, don't want hidden nasty things to be done in my back. I love the simplicity and straightforward way of Arch. This is the perfect definition for Arch, and 100% adhere to it (extract from wiki): "Arch Linux defines simplicity as a lightweight base structure without unnecessary additions, modifications, or complications, that allows an individual user to shape the system according to their own needs. In short; an elegant, minimalist approach." Btw, could be nice to put it in on top of the archlinux.org home page. Olivier
On Wed, 2008-03-26 at 15:46 +0100, olivier bordes wrote:
Hi, exact same for me. "old timer", don't want to be babied, don't want hidden nasty things to be done in my back. I love the simplicity and straightforward way of Arch.
This is the perfect definition for Arch, and 100% adhere to it (extract from wiki):
"Arch Linux defines simplicity as a lightweight base structure without unnecessary additions, modifications, or complications, that allows an individual user to shape the system according to their own needs. In short; an elegant, minimalist approach."
Btw, could be nice to put it in on top of the archlinux.org home page.
Olivier
Guys, childish comments only interrupt developers from getting work done. I believe Roman already told people not to panic. So please just drop it. Regards, Hussam.
On Wed, 26 Mar 2008 17:10:11 +0200 Hussam Al-Tayeb <ht990332@gmail.com> wrote:
Guys, childish comments only interrupt developers from getting work done. I believe Roman already told people not to panic. So please just drop it.
This is the general discussion list after all - the devs don't have to read a line of it if they don't want. I have not seen any "childish" comments here, on either side of a civilised debate. Geoff
Am Mittwoch 26 März 2008 15:46:28 schrieb olivier bordes:
Hi, exact same for me. "old timer", don't want to be babied, don't want hidden nasty things to be done in my back. I love the simplicity and straightforward way of Arch.
I consider myself not a "old timer", I installed Linux in 2005(Ubuntu), but I like "the arch way" very much. Being babied is not a thing I worried about, but about the complexity which has to be added for accomplishing this. Its not an easy task to i.e. - add some patched to installed software - let custom software be traced by the package manager on i.e. Debian based distros. Best, -- Maik
-----Oorspronkelijk bericht----- Van: arch-general-bounces@archlinux.org [mailto:arch-general- bounces@archlinux.org] Namens Aaron Griffin Verzonden: woensdag 26 maart 2008 0:37 Aan: General Discusson about Arch Linux Onderwerp: Re: [arch-general] signoff kernel26-2.6.24.3-6
i believe archlinux is lost and i stopped fighting for it. It's exhausting to fight against argumentation like "but other distros do the same".
people just didnt get the point and should be kicked out of arch
You argue that those people actually contribute too much to kick
On Tue, Mar 25, 2008 at 2:07 PM, Arvid Ephraim Picciani <aep@ibcsolutions.de> wrote: those directly. them out?
Look. they just contribute things that we don't want. We don't want downstream patches. We don't want automatic scripts (except udev, it damn rocks, thanks for that). We don't want downstream split packages. You could safe hundrets of hours by just not doing that.
I am a strong believer that this entire paragraph was constructed by typing "win" over and over.
If patching is no longer allowed, get ready for a time where packages are stuck in testing for ages because upstream broke it. Get ready to run a distro that breaks your system on every pacman -Syu because upgrade paths are not handled. Yes, this is win win win I guess. If we want to go this way, I consider myself as ex-developer and switch to another distribution or operating system that just works and gives me the power to do things the right way. Instead of building packages for people that tell me I'm doing the wrong thing, I'll do upstream software development, in this case GNOME.
On Wed, Mar 26, 2008 at 4:46 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
If patching is no longer allowed, get ready for a time where packages are stuck in testing for ages because upstream broke it. Get ready to run a distro that breaks your system on every pacman -Syu because upgrade paths are not handled. Yes, this is win win win I guess.
Come on, Jan, you know this wasn't the message. It has already been stated that patching *is* allowed (I'd say encouraged) when needed, which means when there's breakage upstream. The point was about superfluous patches, like those that add new functions, which should be sent upstream. I hope this is clear. Corrado
On Mittwoch, 26. März 2008 16:58 bardo wrote:
Come on, Jan, you know this wasn't the message. It has already been stated that patching *is* allowed (I'd say encouraged) when needed, which means when there's breakage upstream. The point was about superfluous patches, like those that add new functions, which should be sent upstream. I hope this is clear.
Now with your words yes but the original can understand in the way how Jan interpret it. Please don't forget that the number one example was the PKGBUILD from kernel26 where the thread starts. And only for the stats: How longer this thread goes i find it confusingly that it is spoken so much from old/new user and i ask myself is this here a one or a two classes community. I must say that i miss here some thinking positive and speaking about the points where the thread starts. This "I am a old user" messages together with statements as "kick out" or "people are lazy" in one thread demotivate more than it helps and gives this discussion the feeling of a waste of time. See you, Attila
On Wed 2008-03-26 16:46 , Jan de Groot wrote:
[...] If patching is no longer allowed, get ready for a time where packages are stuck in testing for ages because upstream broke it. Get ready to run a distro that breaks your system on every pacman -Syu because upgrade paths are not handled. Yes, this is win win win I guess.
If we want to go this way, I consider myself as ex-developer and switch to another distribution or operating system that just works and gives me the power to do things the right way. Instead of building packages for people that tell me I'm doing the wrong thing, I'll do upstream software development, in this case GNOME.
I think we are overrating the problem here. I never saw in Arch's packages patches applied just for fun, or to add useless features. Most of the patches are to make software compile with the new release of gcc, to fix broken makefiles and the like. One of the few packages with a lot of patches is the kernel, but most of them only add hardware support, e.g. I have no idea why mactel patches aren't merged in the vanilla tree, but I'd like to boot Arch on my macbook anyway. IMHO the actual maintainer of kernel26 is doing a good job. If someone wants a kernel26-zomgvanillaistehbest , he can remove all the patches and create the packages by himself. -- Alessio (molok) Bolognino Please send personal email to themolok@gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
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
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.)
Just my humble opinion on some of the issues raised:
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)
+1 PLEASE no more patches that just add functionality! I want VANILLA packages and that's one reason I chose Arch. The users should complain to the specific application's developers for missing functionality and bugs. If arch returns to "the arch way" please remind me to post a list of packages with superfluous patches applied...
* 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)
+1
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? 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.
+1 Again I like respecting the application's developers choices. Dimitris
participants (21)
-
Aaron Griffin
-
Alessio Bolognino
-
Arvid Ephraim Picciani
-
Attila
-
bardo
-
Didi
-
Dimitrios Apostolou
-
Dwight Schauer
-
Filip Wojciechowski
-
Geoff
-
Giovanni Scafora
-
Grigorios Bouzakis
-
Hussam Al-Tayeb
-
Jan de Groot
-
Justin Gx
-
Maik Beckmann
-
olivier bordes
-
RedShift
-
Roman Kyrylych
-
sepht ml
-
w9ya＠qrparci.net