It seems that user patches for a package <category>/<package> are only looked for in a pre-defined set of locations beneath /etc/portage/patches/<category>. Namely, <package>[-<full version>[-r<revision>]][:<slot>] It would be convenient to be able to also specify sub-versions. For example <package>[-<major>[.<minor>[.…]][_<…>][-r<revision>]][:<slot>] I understand that generating directories to search for all possible cases is impractical. Therefore, I think it would be more reasonable for the user-patches code to look if there are any <package>[<whatever>] locations, and then for each <whatever> * split <whatever> into <version+revision> and <slot>, * check the slot, * check if <version+revision> is a pre-[.|_|-|]-prefix of the version+revision string of the package that's being emerged. The last check could be done, I think, by checking if <version+revision> is a prefix and then checking whether the next character in the version+revision string of the package that's being emerged, if any, is ., _, or -. Reproducible: Always
Instead of above described idea (which would change current behavior, potentially causing unintended application of patches), it would be possible to use some prefix (not allowed in package names) in directory name to indicate enabling of full-syntax matching for the following part of directory name. Example: Prefix: "@" Patches for <sys-devel/gcc-8 in: "/etc/portage/patches/sys-devel/@<sys-devel/gcc-8" Patches for =sys-devel/gcc-10* in: "/etc/portage/patches/sys-devel/@=sys-devel/gcc-10*" Since code for matching exists only in Python side of Portage, the easiest implementation would be to call Python from BASH side of Portage (where eapply_user() is implemented): > $ python -c 'import portage.dep; print(portage.dep.Atom("<sys-devel/gcc-8").match("sys-devel/gcc-7.5.0"))' > True
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > Example: > Prefix: "@" > Patches for <sys-devel/gcc-8 in: > "/etc/portage/patches/sys-devel/@<sys-devel/gcc-8" > Patches for =sys-devel/gcc-10* in: > "/etc/portage/patches/sys-devel/@=sys-devel/gcc-10*" I meant: Patches for <sys-devel/gcc-8 in: "/etc/portage/patches/sys-devel/@<gcc-8" Patches for =sys-devel/gcc-10* in: "/etc/portage/patches/sys-devel/@=gcc-10*"
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > Instead of above described idea (which would change current behavior, > potentially causing unintended application of patches), […] The proposal is a natural extension of the current behavior. My guess is that warning users with a news message in advance and/or with a message upon emerge should be enough. Also, the cases where the behavior would change is when a user has specified a sub-version currently and then the patch is currently not applied, which almost certainly wasn't that user's intent (this is actually what happened to me and led me to my proposal). I doubt there are many users that deactivate a patch by renaming the directory it lives in to a shorter one that still corresponds to a valid sub-version. Those few can be warned with the news and/or emerge messages. > it would be possible > to use some prefix (not allowed in package names) in directory name to > indicate enabling of full-syntax matching for the following part of > directory name. Introducing yet-another-syntax, moreover for use in a path, seems inconvenient to me. I think such elaborate syntax belongs in a file, if you want to go that route. That would allow for reuse of notation as is used in files such as package.accept_keywords and package.use. But TBH, I think that is overkill.
(In reply to Erik Quaeghebeur from comment #3) > the cases where the behavior would change is > when a user has specified a sub-version currently and then the patch is > currently not applied I meant situations like this: Some package has versions: 1 1.90 which is how upstream decided to call beta of version 2 Patch for version 1 may be not required or fail to apply for version 1.90 E.g. in KDE Plasma packages, 5.X.90 is beta of 5.(X+1) and not any sub-version of 5.X.
(In reply to comment #1 and comment #2) For more readable review of directory of category, those operators could be moved to the end: Patches for <sys-devel/gcc-8 in: "/etc/portage/patches/sys-devel/gcc@<8" Patches for =sys-devel/gcc-10* in: "/etc/portage/patches/sys-devel/gcc@=10*" Or Exherbo-style syntax dependencies (https://exherbo.org/docs/eapi/exheres-for-smarties.html#package_dependencies) could be used: Patches for <sys-devel/gcc-8 in: "/etc/portage/patches/sys-devel/gcc[<8]" Patches for =sys-devel/gcc-10* in: "/etc/portage/patches/sys-devel/gcc[=10*]"
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #4) > Some package has versions: > 1 > 1.90 which is how upstream decided to call beta of version 2 > Patch for version 1 may be not required or fail to apply for version 1.90 > > E.g. in KDE Plasma packages, 5.X.90 is beta of 5.(X+1) and not any > sub-version of 5.X. That is a good point; I hadn't thought of that… So to deal with this fact, it is necessary to be able to specify half-open version ranges. A minimal proposal for that would be using ‘!’ to indicate ‘but not and beyond’: "package-2.1": only the exact version 2.1 (and perhaps some revisions) [as now] "somepackage-1.2!": any version of which 1.2 is a prefix [what I wanted] "plasma-package-5.3!5.3.90" (anything >=5.3, but not >=5.3.90) [what is needed in some cases] (In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > > Patches for <sys-devel/gcc-8 in: > "/etc/portage/patches/sys-devel/gcc@<8" > Patches for =sys-devel/gcc-10* in: > "/etc/portage/patches/sys-devel/gcc@=10*" Depending on the syntax, this is equally or more expressive than my minimal proposal. It is ‘heavier’ and contains characters that need to be escaped in most shells (>,<). > Or Exherbo-style syntax dependencies > (https://exherbo.org/docs/eapi/exheres-for-smarties. > html#package_dependencies) could be used: > > Patches for <sys-devel/gcc-8 in: > "/etc/portage/patches/sys-devel/gcc[<8]" > Patches for =sys-devel/gcc-10* in: > "/etc/portage/patches/sys-devel/gcc[=10*]" If you consider using the whole exherbo syntax, this would make it very expressive. However, it is heavier still and may require even more escaping. I find both proposals a bit overkill… sorry. But I'm not the one to make that call, Gentoo developers like you should.
(In reply to comment #5) There could simultaneously exist multiple directories matching given package version: E.g. sys-devel/gcc-10.2.0 and these directories: "/etc/portage/patches/sys-devel/gcc[>=7]" "/etc/portage/patches/sys-devel/gcc[>=8]" "/etc/portage/patches/sys-devel/gcc[<11]" Then question is in which order should these directories be used... There is no obviously good choice. Maybe lexicographic order for string between brackets can be used... (In reply to comment #6) Support for single-version Exherbo-style syntax should suffice for now, so without version ranges (e.g. [>=1.2&<2], [=1.1|=1.2|=1.3]). With any solution, I would not be worried about escaping.
We could also just not change anything. I worried that userpatches just becomes too complex. We don't need a turing complete file naming scheme for applying patches; at some point conditional patches means writing code (e.g. copying the ebuild) and not "naming files in some complex way."
