[gentoo-portage-dev] Implement new userpatch feature in existing eclass?

[gentoo-portage-dev] Implement new userpatch feature in existing eclass?

[Nekun]

Hi all.

Recently, I start working on optional atom specifiers feature in 
userpatch facility: if package directory name starts with percent sign, 
following word threated as a regular Portage atom, e.g 
"/etc/portage/patches/sys-kernel/%<=gentoo-sources-5.4" == 
"<=sys-kernel/gentoo-sources-5.4". This might be very useful in cases 
when patches applied to minor updates, but major update breaks it (e.g., 
in Linux kernel), so I want to specify smth like "=gentoo-sources-5.4*". 
I added new command in portageq to match two atoms and call it from 
eapply_user function in phase-function.sh, in same manner as 
has_version/best_version are called it. But recently I found that 
eapply_user implemented in Portage only in EAPI 6, and there is its 
predecessor, epatch_user, implemented in epatch.eclass. So, ebuilds with 
EAPI<6 (I found 4463 in last gentoo snapshot) will ignore new "atomic" 
patch directories. Obviously, this is rather confusing, unacceptable 
behaviour.

Can I patch epatch.eclass in gentoo repository to implement new 
userpatch facility for older EAPIs? I guess that EAPI version is 
considered as stable, unchangeable behaviour of all functions, but in 
other side, this feature doesn't changes anything existing: old 
userpatch semantics preserves and order of applying 
(${P}-${PR},${P},${PN}) not changed, seeking for atoms added at tail.

Re: [gentoo-portage-dev] Implement new userpatch feature in existing eclass?

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1737 bytes --]

On 4/4/21 10:54 AM, Nekun wrote:
> Hi all.
> 
> Recently, I start working on optional atom specifiers feature in
> userpatch facility: if package directory name starts with percent sign,
> following word threated as a regular Portage atom, e.g
> "/etc/portage/patches/sys-kernel/%<=gentoo-sources-5.4" ==
> "<=sys-kernel/gentoo-sources-5.4". This might be very useful in cases
> when patches applied to minor updates, but major update breaks it (e.g.,
> in Linux kernel), so I want to specify smth like "=gentoo-sources-5.4*".
> I added new command in portageq to match two atoms and call it from
> eapply_user function in phase-function.sh, in same manner as
> has_version/best_version are called it. But recently I found that
> eapply_user implemented in Portage only in EAPI 6, and there is its
> predecessor, epatch_user, implemented in epatch.eclass. So, ebuilds with
> EAPI<6 (I found 4463 in last gentoo snapshot) will ignore new "atomic"
> patch directories. Obviously, this is rather confusing, unacceptable
> behaviour.
> 
> Can I patch epatch.eclass in gentoo repository to implement new
> userpatch facility for older EAPIs? I guess that EAPI version is
> considered as stable, unchangeable behaviour of all functions, but in
> other side, this feature doesn't changes anything existing: old
> userpatch semantics preserves and order of applying
> (${P}-${PR},${P},${PN}) not changed, seeking for atoms added at tail.
> 

Today, I count only 2445, or 8.3% of ebuilds have EAPI 5.

I imagine that the migration is moving along, since we deprecated EAPI 5
on 2020-11-26 here:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b2e281bb698eb93704e1987dc4df1cf2dd3c2cff

-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-portage-dev] Implement new userpatch feature in existing eclass?

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1735 bytes --]

On 4/4/21 10:54 AM, Nekun wrote:
> Hi all.
> 
> Recently, I start working on optional atom specifiers feature in
> userpatch facility: if package directory name starts with percent sign,
> following word threated as a regular Portage atom, e.g
> "/etc/portage/patches/sys-kernel/%<=gentoo-sources-5.4" ==
> "<=sys-kernel/gentoo-sources-5.4". This might be very useful in cases
> when patches applied to minor updates, but major update breaks it (e.g.,
> in Linux kernel), so I want to specify smth like "=gentoo-sources-5.4*".
> I added new command in portageq to match two atoms and call it from
> eapply_user function in phase-function.sh, in same manner as
> has_version/best_version are called it. But recently I found that
> eapply_user implemented in Portage only in EAPI 6, and there is its
> predecessor, epatch_user, implemented in epatch.eclass. So, ebuilds with
> EAPI<6 (I found 4463 in last gentoo snapshot) will ignore new "atomic"
> patch directories. Obviously, this is rather confusing, unacceptable
> behaviour.
> 
> Can I patch epatch.eclass in gentoo repository to implement new
> userpatch facility for older EAPIs? I guess that EAPI version is
> considered as stable, unchangeable behaviour of all functions, but in
> other side, this feature doesn't changes anything existing: old
> userpatch semantics preserves and order of applying
> (${P}-${PR},${P},${PN}) not changed, seeking for atoms added at tail.
> 

Today, I count only 2445, or 8.3% of ebuilds have EAPI 5.

I imagine that the migration is moving along, since we deprecated EAPI 5
on 2020-11-26 here:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b2e281bb698eb93704e1987dc4df1cf2dd3c2cff
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-portage-dev] Implement new userpatch feature in existing eclass?

[Nekun]

On 2021-04-04 20:49, Zac Medico wrote:
> 
> Today, I count only 2445, or 8.3% of ebuilds have EAPI 5.
> 
> I imagine that the migration is moving along, since we deprecated EAPI 
> 5
> on 2020-11-26 here:
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b2e281bb698eb93704e1987dc4df1cf2dd3c2cff

Thanks for the reply.

Also, I found that all functions which perform portageq calls should be 
pass-able to ebuild-ipc daemon and all that existing functions is a 
members of EAPI, declared in bin/eapi.sh. Should I add my portageq 
wrapper called from eapply_user to EAPI? In the other side, this wrapper 
is not intended to be called directly from ebuilds...