| 1 |
On Tue, Jun 22, 2021 at 12:06 PM Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> |
| 3 |
> >>>>> On Tue, 22 Jun 2021, Marek Szuba wrote: |
| 4 |
> |
| 5 |
> > Seeing as in the end this USE flag is not going anywhere in spite of |
| 6 |
> > Gentoo no longer providing PaX-capable kernel sources, could we please |
| 7 |
> > rename it (e.g. to 'pax-kernel') so that it no longer contains a |
| 8 |
> > disallowed character. I understand the main reason this hasn't been |
| 9 |
> > done yet is that we expected it might disappear altogether. |
| 10 |
> |
| 11 |
> +1 for renaming to pax-kernel. |
| 12 |
> |
| 13 |
> A related question, the pax_kernel flag is still used by these packages: |
| 14 |
> |
| 15 |
> app-emulation/virtualbox |
| 16 |
> app-emulation/virtualbox-modules |
| 17 |
> dev-java/icedtea |
| 18 |
> dev-lang/mlton |
| 19 |
> dev-lang/mono |
| 20 |
> dev-lang/smlnj |
| 21 |
> dev-libs/libffi |
| 22 |
> dev-libs/libffi-compat |
| 23 |
> media-sound/spotify |
| 24 |
> net-libs/nodejs |
| 25 |
> |
| 26 |
> From my past experience with PaX support in Emacs, things used to break |
| 27 |
> on a regular basis [1]. So I wonder, how is the status of PaX support in |
| 28 |
> the packages listed above? Do their maintainers actually test them with |
| 29 |
> a PaX kernel (which would be a third-party kernel, I suppose)? If not, |
| 30 |
> maybe the flag should be removed from these untested packages? |
| 31 |
|
| 32 |
ebuild maintainers are rarely responsible for the PaX-related |
| 33 |
workarounds that end up in ebuilds. A better question would be if |
| 34 |
*anybody* is using these packages with a PaX-enabled kernel, and |
| 35 |
that's more difficult to answer. |
Archives