| Summary: | eutils.eclass: epatch_user: add /etc/portage/package.patches to search list | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | charles17 |
| Component: | Eclasses | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | minor | CC: | dev-portage, qa |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
we can add support for package.patches, but i don't see us dropping the current path the current path also has an argument for it in the sense that package.xxx is kind of reserved by portage (although you could say that all of /etc/portage is reserved by portage) I strongly object to adding any new /etc/portage path in eutils. (In reply to Michał Górny from comment #2) you didn't provide any reasoning at all portage: are there any plans cooking to utilize package.patches ? or do we prefer to keep that namespace clear ? (In reply to SpanKY from comment #3) > (In reply to Michał Górny from comment #2) > > you didn't provide any reasoning at all The reasoning: /etc/portage is for paths utilized by *Portage*, the package manager, not random functions from random eclasses. Whole /etc/portage is reserved for Portage, without any exceptions. (In reply to SpanKY from comment #3) > portage: are there any plans cooking to utilize package.patches ? or do we > prefer to keep that namespace clear ? Well, eappy_user is already included in EAPI 6, and it uses /etc/portage/patches just like epatch_user does: https://gitweb.gentoo.org/proj/portage.git/commit/?id=f188c989317a58ffc54cc0c022c728c100de9000 As EAPI 5 and earlier gradually die off, so will epatch_user. If we'd like portage to use /etc/portage/package.patches for eapply_user, then we should make that decision before EAPI 6 is finalized. |
Presently epatch_user uses ${PORTAGE_CONFIGROOT%/}/etc/portage/patches However the regular file/directory names for package specific information is like: /etc/portage/package.accept_keywords /etc/portage/package.unmask /etc/portage/package.env /etc/portage/package.use /etc/portage/package.license /etc/portage/package.mask So ${PORTAGE_CONFIGROOT%/} should also use the "package." prefix: /etc/portage/package.patches