EAPI 6

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

EAPI 6

Samuel Bernardo
Hi,

Is there any way to allow EAPI 6 for some overlays with current portage
stable version (2.3.89-r1)?

There are many previous functions that were updated strictly to EAPI 7.
As an example here is the result when running "eix-sync -a":

> ebuild failed with status
> 1                                                                                                                                                                                                                                                  
>  
>      Reading category 127|190 ( 66):
> net-misc...                                                                                                                                                                                                                             
>  
> cannot properly execute
> /var/lib/layman/go-overlay/net-misc/dbxcli/dbxcli-1.4.0.ebuild
>      Reading category 127|190 ( 66): net-misc... * ERROR:
> net-misc/gnatsd-0.9.4::go-overlay failed (depend
> phase):                     
>  *   golang-common: EAPI=6 is not
> supported                                                                                          
>  
>  *                                                        
>  * Call
> stack:                                                                                                                       
>  
>  *              ebuild.sh, line 609:  Called source
> '/var/lib/layman/go-overlay/net-misc/gnatsd/gnatsd-0.9.4.ebuild'
>  *    gnatsd-0.9.4.ebuild, line  10:  Called inherit
> 'golang-single'                                                                 
>  
>  *              ebuild.sh, line 314:  Called __qa_source
> '/var/lib/layman/go-overlay/eclass/golang-single.eclass'
>  *              ebuild.sh, line 112:  Called source
> '/var/lib/layman/go-overlay/eclass/golang-single.eclass'                         
>  
>  *   golang-single.eclass, line  66:  Called inherit
> 'golang-common'                                                  
>  *              ebuild.sh, line 314:  Called __qa_source
> '/var/lib/layman/go-overlay/eclass/golang-common.eclass'
>  *              ebuild.sh, line 112:  Called source
> '/var/lib/layman/go-overlay/eclass/golang-common.eclass'     
>  *   golang-common.eclass, line  37:  Called
> die                                                                                     
>  
>  * The specific snippet of
> code:                                                                                                     
>  
>  *              die "${ECLASS}: EAPI=${EAPI:-0} is not supported"
> ;;                                             
>  *                                                                                                                                   
>  
>  * If you need support, post the output of `emerge --info
> '=net-misc/gnatsd-0.9.4::go-overlay'`,                                     
>  
>  * the complete build log and the output of `emerge -pqv
> '=net-misc/gnatsd-0.9.4::go-overlay'`.                                      
>  
>  * Working directory:
> '/usr/lib64/python3.6/site-packages'                                                                           
>  
>  * S: '/gnatsd-0.9.4'
Thanks in advance for your help, comments and suggestions.

Best,

Samuel


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EAPI 6

Samuel Bernardo
Hi again,

As a suggestion, I would propose for each overlay to override the eclass
functions for those necessary to EAPI 6 within their ebuilds.

For instance, go-overlay could use old eclasses that support EAPI 6
overriding the current ones. For some reason they updated their eclasses
to  EAPI 7 before updating the ebuilds.

This brings me to the main issue that is the portage cache and possible
conficts between those eclass defined in the overlay and those from
gentoo main stream. Maybe a name convention would be useful here for
future upgrades as a code styling guide for gentoo developers.

What do you think about this kind of issues?

Best,

Samuel

On 12/03/2020 10.42, Samuel Bernardo wrote:

> Hi,
>
> Is there any way to allow EAPI 6 for some overlays with current portage
> stable version (2.3.89-r1)?
>
> There are many previous functions that were updated strictly to EAPI 7.
> As an example here is the result when running "eix-sync -a":
>
>> ebuild failed with status
>> 1                                                                                                                                                                                                                                                  
>>  
>>      Reading category 127|190 ( 66):
>> net-misc...                                                                                                                                                                                                                             
>>  
>> cannot properly execute
>> /var/lib/layman/go-overlay/net-misc/dbxcli/dbxcli-1.4.0.ebuild
>>      Reading category 127|190 ( 66): net-misc... * ERROR:
>> net-misc/gnatsd-0.9.4::go-overlay failed (depend
>> phase):                     
>>  *   golang-common: EAPI=6 is not
>> supported                                                                                          
>>  
>>  *                                                        
>>  * Call
>> stack:                                                                                                                       
>>  
>>  *              ebuild.sh, line 609:  Called source
>> '/var/lib/layman/go-overlay/net-misc/gnatsd/gnatsd-0.9.4.ebuild'
>>  *    gnatsd-0.9.4.ebuild, line  10:  Called inherit
>> 'golang-single'                                                                 
>>  
>>  *              ebuild.sh, line 314:  Called __qa_source
>> '/var/lib/layman/go-overlay/eclass/golang-single.eclass'
>>  *              ebuild.sh, line 112:  Called source
>> '/var/lib/layman/go-overlay/eclass/golang-single.eclass'                         
>>  
>>  *   golang-single.eclass, line  66:  Called inherit
>> 'golang-common'                                                  
>>  *              ebuild.sh, line 314:  Called __qa_source
>> '/var/lib/layman/go-overlay/eclass/golang-common.eclass'
>>  *              ebuild.sh, line 112:  Called source
>> '/var/lib/layman/go-overlay/eclass/golang-common.eclass'     
>>  *   golang-common.eclass, line  37:  Called
>> die                                                                                     
>>  
>>  * The specific snippet of
>> code:                                                                                                     
>>  
>>  *              die "${ECLASS}: EAPI=${EAPI:-0} is not supported"
>> ;;                                             
>>  *                                                                                                                                   
>>  
>>  * If you need support, post the output of `emerge --info
>> '=net-misc/gnatsd-0.9.4::go-overlay'`,                                     
>>  
>>  * the complete build log and the output of `emerge -pqv
>> '=net-misc/gnatsd-0.9.4::go-overlay'`.                                      
>>  
>>  * Working directory:
>> '/usr/lib64/python3.6/site-packages'                                                                           
>>  
>>  * S: '/gnatsd-0.9.4'
> Thanks in advance for your help, comments and suggestions.
>
> Best,
>
> Samuel
>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EAPI 6

Zac Medico-2
On 3/14/20 7:20 AM, Samuel Bernardo wrote:
> Hi again,
>
> As a suggestion, I would propose for each overlay to override the eclass
> functions for those necessary to EAPI 6 within their ebuilds.

Yes, either do that or upgrade EAPI in the ebuilds.

> For instance, go-overlay could use old eclasses that support EAPI 6
> overriding the current ones. For some reason they updated their eclasses
> to  EAPI 7 before updating the ebuilds.

Apparently the go-overlay sabotaged itself with this commit:

https://github.com/Dr-Terrible/go-overlay/commit/2b5bfa01bf8777f28f57eb5b7da2ccde4ace744b#diff-2e747d04b1138fffb99dbb6a5fdd6c1b

> This brings me to the main issue that is the portage cache and possible
> conficts between those eclass defined in the overlay and those from
> gentoo main stream. Maybe a name convention would be useful here for
> future upgrades as a code styling guide for gentoo developers.

There's no conflict. Overlays are free to override eclasses as needed.

> What do you think about this kind of issues?

It's not a good idea for overlays to make eclass changes that break
their own ebuilds.

> Best,
>
> Samuel
>
> On 12/03/2020 10.42, Samuel Bernardo wrote:
>> Hi,
>>
>> Is there any way to allow EAPI 6 for some overlays with current portage
>> stable version (2.3.89-r1)?

The portage version is irrelevant. All versions of portage are backward
compatible with all old EAPIs.

--
Thanks,
Zac


signature.asc (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EAPI 6

Samuel Bernardo
Thank you very much Zac for your answers.

I was wondering if I was missing any coding convention after reading
[1], since I always follow the pattern to define eclasses inside my
overlays as needed, sometimes overriding those provided from gentoo
portage. I was not sure if I was doing the development breaking the
expected QA rules.

With your explanation I know now that I'm doing it the right way.

[1]
https://devmanual.gentoo.org/appendices/common-problems/index.html#qa-notice----eclass-foo-inherited-illegally




signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EAPI 6

Zac Medico-2
On 3/14/20 1:40 PM, Samuel Bernardo wrote:

> Thank you very much Zac for your answers.
>
> I was wondering if I was missing any coding convention after reading
> [1], since I always follow the pattern to define eclasses inside my
> overlays as needed, sometimes overriding those provided from gentoo
> portage. I was not sure if I was doing the development breaking the
> expected QA rules.
>
> With your explanation I know now that I'm doing it the right way.
>
> [1]
> https://devmanual.gentoo.org/appendices/common-problems/index.html#qa-notice----eclass-foo-inherited-illegally
The stale cache issues that are mentioned there only applied to the
'pms' cache format which should not be used since around 2012/2013 when
we changed the default for the metadata/layout.conf cache-formats
setting here:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=e760c8d2a4ccc56e351ac37904c715f596b58e42
--
Thanks,
Zac


signature.asc (1000 bytes) Download Attachment