[arch-dev-public] providing grsecurity in [community]

Allan McRae allan at archlinux.org
Tue Apr 22 06:03:38 EDT 2014

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.

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.

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.

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.

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...)

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.


More information about the arch-dev-public mailing list