| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change reworks the patching logic entirely to avoid the use of a
sequence file, instead, relying on directory sort order and numerically
prefixed filenames.
In addition to this change, work is done on the patchset authoring side
to pre-extract important fields like "bugs" and "description" for the
patches and puts them in easy to read files, in order to more clearly
generate patchlevel_gentoo.h ( seen in Perl -V )
Perl -V now includes more verbose details, including fully qualified bug
URLs.
Additionally, its more straight forward to add records to the patch
bundle within the ebuild, using the new "add_patch" helper, so that even
files applied from ${FILESDIR} can be shown in `perl -V`
Patches are fully re-rolled as git patches against perl v5.30.3
Sourcing from "mirror://gentoo" is now implicit, as this syntax is
discouraged.
Patch for Net::SNMP removed from bundle as it just now introduces
redundant documentation.
Patch for gentoo-libdirs now bundled, and properly rehashed to avoid
failing in various porting tests.
Package-Manager: Portage-2.3.100, Repoman-2.3.22
Signed-off-by: Kent Fredric <kentnl@gentoo.org>
|
|
|
This is a work in-progress experiment, hence, it is unkeyworded until
I can get more eyes on the changes, and fully test the consequences at
scale.
Important Changes:
- Convert to EAPI7
- Remove inherit on eutils
- Replace calls to "epatch" to "eapply", but resulting in a loss of
nice output
- Add new hidden feature PERL_SINGLE_SLOT, which, when set, installs
perl into a directory named after SUBSLOT (eg: 5.30) as opposed to one
following the explicit name (eg: 5.30.2), which aims to pre-emptively
solve (in both direction) the problem faced by shipping binpkg's,
where the built perl has only one set of INC dirs (eg: 5.30.2), but a
binpkg was built with a different, but compatible perl (eg: 5.30.1),
and subsequently, installs to an @INC dir that is not visible to the
built perl. Instead, all perl's that are defined to be
inter-compatible share the same directory for both arch-dependent and
arch-independent code, so binpkg's only need to be regenerated when:
- Upgrading/downgrading between major revisions
- Flipping USE="debug" or USE="ithreads".
Under PERL_SINGLE_SLOT, directories that should be compatible, and are
available, but built under the previous scheme, are also inhaled into
@INC for ease of transition.
The name of this flag is subject to change, and may become a USE flag.
- Add a new hidden feature PERL_SUPPORT_SINGLE_SLOT, which builds perl
the same way as in previous versions, but also probes for version'd
directories generated by installing packages on perl's built with
PERL_SINGLE_SLOT, as a fallback mechaism for transitioning away from a
perl built with PERL_SINGLE_SLOT.
The name of this flag is subject to change, and may become a USE flag
- Add a patch to various parts of Configure, perl.c, and friends, to
facilitate the above, which exposes itself as -Dgentoolibdirs=, and
has the same syntax as -Dotherlibdirs, but doesn't pollute everything
by adding its own arch-dirs when they weren't asked for. This patch
may also later help facilitate building perl's without
PERL_SINGLE_SLOT, but with other @INC dirs forced into place, for the
same purpose, but implemented differently, as the previous mechanism,
-Dinc_version_list is limited in that it:
- Excludes internally directories that don't exist
- Mangles directories sometimes trashing @INC entirely, throwing
away litterally all the versions you passed.
- Fixed a very embarrasing typo in the einfo code, ${EROO%/T} ...
- Restructured the @INC discovery/cleanup logic into dedicated functions
- Add more error handling in the discovery path, especially adding loud
error output if directories that *need* to be traversed for compat
discovery cannot be traversed, due to misconfigured permissions.
- Fix an embarrasing bug in @INC list stripping, that due to inherently
being a *substring* match, not a *fullstring* match, could have
excluded 5.30.20 from the @INC path for 5.30.2, even though they're
intercompatible. This became more obvious, when one was trying to
strip '5.30' from a list that contained '5.30.1', '5.30.2', because it
just ate everything!
Questions:
- Why do we have bzip2 in RDEPEND? Surely, that should be BDEPEND-only
- Are we even using bzip2 anymore?
- Should we migrate the patch ball to being a more-common-these-days set
of numerically ordered patches, and potentially reduce the handling
complexity in the ebuild as a result?
Package-Manager: Portage-2.3.100, Repoman-2.3.22
Signed-off-by: Kent Fredric <kentnl@gentoo.org>
|
Fabian Groffen
Kent Fredric
GitWeb