On 22/04/14 06:03 AM, Allan McRae wrote:
Lets not draw this out too much further. I don't want to have to unsubscribe from another mailing list... But I am still going to have my say!
1) This was different than every other package in [community]. I know this because packages get added to [community] all the time without an email here. And saying discussion about adding PaX extensions was makes it different is naive as anyone who has been around here a short time could tell you that was never going to happen.
I didn't expect much from that proposal but it was worth trying. It's now clear to me that it's never going to happen. It was less of a pipe dream than enabling SELinux support in many packages + shipping complex policies via labels on files/directories :).
2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced.
Output from `uname -a` or `dmesg` is a pretty basic requirement for a kernel issue, especially since problems like /boot not being mounted and new upgrades installed to the wrong place often happen. I don't mind being the one who asks for this on any [linux] issues missing it. I'll have to dig up the old discussion because I wasn't around for it.
3) Now this is in [community] there will be an expectation of providing all the extras that are supposed to come with this. As decided, this will not be happening, but it will be expected and the question will need to be answered repeatedly.
Whether or not the kernel is in the repositories, I'm going to be maintaining the userspace components in [community] so there is going to an expectation of support (from me). Rather than providing the PaX exceptions via file attributes, it can be done via an RBAC policy. If I didn't think I could provide all of the extras, I wouldn't be taking on the responsibility. https://bugs.archlinux.org/task/39983 The downside of this solution from a user perspective is that it won't work for the PaX subset alone (linux-pax, which I have no interest in) so the hacks in the AUR will stay around. It also means extra pain for me since it's not yet written, but no one else has to worry about that.
4) A separate repo would have given actual number for interest in this. We all know the number of votes in the AUR is a crap metric and could have accumulated a long time ago. It would also have allowed us to see how important the above issues are. Despite assertions, many binary repos are well used by the Arch community.
If what ends up happening is that it sees little use and/or causes work for other people, it can be dropped again. I don't think we're ever going to find that out from an unofficial repository. At the very least moving it to [community] is going to make a bunch of people angry about it and we can get to a resolution faster.
5) There were objections to it being included in our binary repos. This does not happen often, but we usually discuss further and come to a consensus about inclusion. Ignoring those objections is not how our team works. Given the relatively few people who responded to the thread, we have no real idea what the support was (and I can provide unsupported anecdotes for support against or for inclusion of the package as well as the next person can...)
I know there were objections, but as you said few people felt like voicing their opinion here. A real vote would make sense but I don't see value in arguing in circles with the same few people. I'm not ignoring real issues that are raised, like the added work of distinguishing between which kernel users are using. I'm willing to put in whatever time is required to prevent this from increasing the workload of people who aren't interested in it. If that means stepping up and beginning to help with [linux] bug triage, I can do that.
In conclusion, this should have waited before being put in the repo. It might have ended up there anyway, it might not have. And I can not be bothered figuring it out as it will not affect me in any way.
If the end result is that it ends up back in the AUR, that's fine. I moved it because I didn't feel this was a productive discussion anymore. Arguing about this on the mailing list for weeks is going to cause much more pain than it simply being in [community].