Ever since an old patch version, it has (for reasonable security
reasons) not supported patched with ../ in the filename.
Many of our patches have been relying on this behaviour being OK,
because we start off with an ancient patch version that didn't perform
such checks. As soon as we need this behaviour after we build a newer
patch though, we will have problems.
So, let's change the policy.
Patches are relative to where tarballs are extracted, rather than the
"working directory" - e.g. have patches for `coreutils-9.4/src/cp.c`
instead of `src/cp.c`.
Keeping this consistent has a few implications;
- patches are applied from the build/ directory in bash era now, with
`-p0`
- when patches are manually applied in the bash era, use `-p` as
required, usually `-p1`
- in kaem era where patches are always manually applied, `-p1` is used
There isn't really any reason to use gzip instead of bzip2 for the Linux
initramfs/kernel, since we have it!
Saves a few MB (~13MB as far as I can tell)
This is a continuation of the 4.14 series by the Open Enterprise Linux
Alliance, ostensibly to the same maintenance standards as the now
discontinued kernel.org LTS.
This code is primarily offered as a Git repository, with gz tarballs
also available, but no xz versions. Switching back to a gzipped version
of the kernel source code would introduce too much srcfs growth, so we
use the last kernel.org tar.xz release (4.14.336), and apply OpenELA's
changes using a patch generated from the Git repository.
