On 02/06/2024 18.40, Ulrich Mueller wrote:
On Sun, 02 Jun 2024, Florian Schmaus wrote:
IMHO that's a very bad idea and will probably break ebuilds that rely
on the current behaviour.
I pondered about this and its one of the reasons I'd rather start with
a fresh eclass.
That said, worst c
> On Sun, 02 Jun 2024, Florian Schmaus wrote:
>> IMHO that's a very bad idea and will probably break ebuilds that rely
>> on the current behaviour.
> I pondered about this and its one of the reasons I'd rather start with
> a fresh eclass.
> That said, worst case scenario I could came up with
On 02/06/2024 17.25, Ulrich Mueller wrote:
On Sun, 02 Jun 2024, Florian Schmaus wrote:
Note that this changes readme.gentoo-r1.eclass to export phase
functions when it previously did not.
IMHO that's a very bad idea and will probably break ebuilds that rely
on the current behaviour.
I pond
> On Sun, 02 Jun 2024, Florian Schmaus wrote:
> Note that this changes readme.gentoo-r1.eclass to export phase
> functions when it previously did not.
IMHO that's a very bad idea and will probably break ebuilds that rely
on the current behaviour.
(Also, readme.gentoo.eclass used to export ph
Following up on the comments of the last patchset, this revision
incorporates the functionality of the initially proposed
greadme.eclass into the existing readme.gentoo-r1.eclass. While this
misses the chance to get rid of some ballast of the existing eclass,
people asked to extend the existing ecl
