On Nov 9, 2007 7:45 AM, James <iphitus@gmail.com> wrote:
Lets look at this differently. To put it lightly, editing the kernel26 pkgbuild to add/remove things, can be daunting for most or annoying to do every release. This is why they want us to do it. Why don't we make the kernel26 PKGBUILD a bit more adaptable/friendly?
YES YES YES! Thank you for bringing this up. For that matter, I tried and failed at this because we use too much damn magic in our PKGBUILD! I've custom compiled my own TRUE vanilla kernel for one of my boxes, and I didn't use this PKGBUILD because it is just way too hard to decipher. Can someone please clean this up? I don't care if we have a select group of devs that are our "kernel maintainers"- it shouldn't take a rocket scientist to change this PKGBUILD and know what is going on. Why is there a 'yes "" | make config' in there? What is this sed EXTRAVERSION line? Do we even need the System.map file anymore? Add headers for lirc package, wtf? dm headers, inotify, blah blah, blah. This is a ridiculous PKGBUILD that two people know what is going on, and that is unacceptable. On Nov 9, 2007 8:59 AM, Thomas Bächler <thomas@archlinux.org> wrote:
I was about to start this thread just this morning, but didn't have the time. Here is what I think: The Arch way is to keep things as untouched as possible and frankly, our kernel has become full of stuff that I don't see a reason for.
dmcgee@dublin /var/abs/core/base/kernel26 $ ls | wc -l 38 Wow. I agree that this is getting out of hand. We need 38 files to build a "vanilla" kernel? As I said above, what happened to the make/make install concept?
* acpi-dsdt-initrd-v0.8.4-2.6.21.patch
What I definitely don't like about the patch is that the ACPI subsystem has changed substantially since 2.6.21 - the fact that the patch still applies doesn't mean it doesn't introduce unwanted and stupid behaviour, or hidden bugs. None of us would know the problems the patch may cause, as none of us knows anything about kernel/ACPI code.
And if it hasn't been merged upstream, then there is an issue here.
* toshiba-bluetooth.patch
Die.
* http://www.archlinux.org/~tpowa/alsa-patches/alsa-20071109.patch.bz2 *http://www.archlinux.org/~tpowa/alsa-patches/alsa-include-20071109.patch.bz2
Why do we update alsa all the time, especially to non-released versions? This may have been necessary, when a large number of chipsets were broken, but I don't think that is still the case. Is there any specific reasons we cannot stick with the alsa version that Linux provides?
I agree with Thomas here.
* acpi-buggy-bios.patch
Like mactel, this patch has been there since .20 or so, the ACPI implementation has had many changes, and it is more likely that it introduces bugs than that it fixes any. Again, this patch should be removed for one of the above reasons.
Die.
squashfs3.2-patch.bz2 http://download.filesystems.org/unionfs/unionfs-2.1/unionfs-2.1.8_for_2.6.23...
Why are none of these merged upstream? Why do we have to add features ourselves? I know we had problems with externally built unionfs, but adding it in-kernel shouldn't be the solution, especially because it results in more work maintaining.
* put_filp.patch * lhash-2.6.22.patch
I don't know what these are, but these seem to be new bugfixes. Still, it should be evaluated if they are still needed before they are added again in 2.6.24.
Document these patches please.
hibernate-saa7134.diff
How long has this been sitting here? Again, the "why hasn't it been merged" question should be asked, and the patch removed, most likely.
Agree.
sata_sis-2.6.23.patch ipw2x00-2.6.23.patch zd1211rw-oops-2.6.23.patch ide-helper-2.6.23.patch
I guess those are new, so again, we can keep them until .24, but they should be fixed by then and our patches removed.
* linux-phc-0.3.0-kernel-vanilla-2.6.23rc3.patch
This is an extra feature. One that a small minority of people can use. It is said to be unintrusive, but then, why isn't it in the upstream version? If it is so unintrusive, the upstream devs shouldn't object to adding it. So either it was never submitted or it was rejected for a good reason.
<sarcasm>Glad that it got added without much discussion.</sarcasm>
# genpatches from gentoo * 2405_hostap-netdev-type.patch * 2525_usb-storage-nikon-d200-quirk.patch * 2530_usb-storage-nikon-d40x-quirk.patch
What do these do? Why do we need them?
* pre-2.6.23.2.patch
Where does this patch come from? Where is it (not in our CVS)? The 2.6.23.y git tree shows no new patches since .23.1, so I would at least like a comment about it.
My opinion is, we should remove most of the above patches as 1) we don't know what bugs they may introduce, 2) they haven't been merged upstream for a reason or 3) they have been merged but in a different way, introducing two fixes for the same problem, and the one in the vanilla kernel is most likely much cleaner.
It appears to me that tpowa often blindly adds patches that are submitted, with the only condition that they apply and build.
I want to reduce the number of patches applied to our kernel, and I want that any patch that adds a new feature or bugfix MUST be merged in a future version. If a patch has never been submitted, it should be submitted, if it has been submitted and rejected, it should be dropped.
I agree with Thomas' sentiment here. We seem to be deviating from our own "strictly vanilla" kernel rules a bit too much. At every major kernel release, *every* patch should be reviewed and a decision made on future inclusion. I'm not asking for an all-dev vote here or anything, as that would be stupid, but I am asking for more than one person to decide. I don't mean to come across as critical here, as I appreciate you guys maintaining the kernel. But I think we need to continuously improve what we do, and this is one of those areas we could do that in. -Dan