Re: [gentoo-dev] autotools.eclass and EAPI 7
Ühel kenal päeval, R, 17.08.2018 kell 15:15, kirjutas Alexis Ballier: > On Thu, 16 Aug 2018 21:36:56 +0300 > Mart Raudsepp wrote: > > > Ühel kenal päeval, N, 16.08.2018 kell 14:27, kirjutas Brian Evans: > > > There are currently a handful of ebuilds using EAPI 7 and the > > > autotools > > > eclass. > > > > > > I believe that this eclass should be reviewed for adding BDEPEND > > > or > > > having BDEPEND replace the DEPEND statement as the default action > > > of > > > the > > > eclass. > > > > > > Other items might be needed, but that's doubtful. > > > > > > Someone please advise the best course of action and either do it > > > or > > > I will propose a patch based on the discussion. > > > > > > > Could or did someone also check through all the other eclasses that > > don't have any global EAPI compatibility checks? > > For the future, maybe it's better to add such a check - just > > accepting > > 0-7 or so, but unsure about all these custom EAPIs out there, might > > force more eclass copying to some overlays. > > I don't really like that kind of checks: untested after usually small > changes != broken. > > IMHO a better solution could be to have council members review all > eclasses prior to approving an eapi and either adding a comment why + > a > die when used with the not-yet-approved-eapi if the eclass requires > changes or do nothing about it if it's fine. This has the double > advantage to give council members first hands experience with an eapi > before approving/voting it and ensures better migration when eapi is > approved. I think that's a good idea, in some form, but that ship has sailed with EAPI-7 now and the request remains. I'll try to remember this for a future EAPI-8 in the future. I'd be glad to review things now, if I had time, but frankly I have much more important things on my plate right now (like getting other things to the point I can review and merge EAPI-7 support to some of the eclasses I maintain and unblock progress for more usage of it). Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] autotools.eclass and EAPI 7
On Thu, 16 Aug 2018 21:36:56 +0300 Mart Raudsepp wrote: > Ühel kenal päeval, N, 16.08.2018 kell 14:27, kirjutas Brian Evans: > > There are currently a handful of ebuilds using EAPI 7 and the > > autotools > > eclass. > > > > I believe that this eclass should be reviewed for adding BDEPEND or > > having BDEPEND replace the DEPEND statement as the default action of > > the > > eclass. > > > > Other items might be needed, but that's doubtful. > > > > Someone please advise the best course of action and either do it or > > I will propose a patch based on the discussion. > > > > Could or did someone also check through all the other eclasses that > don't have any global EAPI compatibility checks? > For the future, maybe it's better to add such a check - just accepting > 0-7 or so, but unsure about all these custom EAPIs out there, might > force more eclass copying to some overlays. I don't really like that kind of checks: untested after usually small changes != broken. IMHO a better solution could be to have council members review all eclasses prior to approving an eapi and either adding a comment why + a die when used with the not-yet-approved-eapi if the eclass requires changes or do nothing about it if it's fine. This has the double advantage to give council members first hands experience with an eapi before approving/voting it and ensures better migration when eapi is approved.
Re: [gentoo-dev] autotools.eclass and EAPI 7
Ühel kenal päeval, N, 16.08.2018 kell 14:27, kirjutas Brian Evans: > There are currently a handful of ebuilds using EAPI 7 and the > autotools > eclass. > > I believe that this eclass should be reviewed for adding BDEPEND or > having BDEPEND replace the DEPEND statement as the default action of > the > eclass. > > Other items might be needed, but that's doubtful. > > Someone please advise the best course of action and either do it or I > will propose a patch based on the discussion. > Could or did someone also check through all the other eclasses that don't have any global EAPI compatibility checks? For the future, maybe it's better to add such a check - just accepting 0-7 or so, but unsure about all these custom EAPIs out there, might force more eclass copying to some overlays. Mart signature.asc Description: This is a digitally signed message part
[gentoo-dev] autotools.eclass and EAPI 7
There are currently a handful of ebuilds using EAPI 7 and the autotools eclass. I believe that this eclass should be reviewed for adding BDEPEND or having BDEPEND replace the DEPEND statement as the default action of the eclass. Other items might be needed, but that's doubtful. Someone please advise the best course of action and either do it or I will propose a patch based on the discussion. Thanks. Brian signature.asc Description: OpenPGP digital signature
