Brian Harring schrieb:
> On Tue, Jun 19, 2012 at 08:54:07PM +0200, Thomas Sachau wrote:
>> Ciaran McCreesh schrieb:
>>> On Tue, 19 Jun 2012 20:16:39 +0200
>>> Thomas Sachau <firstname.lastname@example.org> wrote:
>>>> Since there is again no response at all, it seems like everyone is ok
>>>> with this, so i will propose to add this to the next council agenda
>>>> for EAPI-5 addition.
>>> Got a diff for PMS?
>> Last time you only requested enough details for implementation, you did
>> not require a PMS diff, so i wrote more details for the implementation.
>> If you, Brian (for pkgcore) and zmedico accept this for EAPI-5, i might
>> look into creating a diff against PMS but until then, i dont want to
>> waste my time, especially since noone commented on the implementation
>> details or the technical details and any change would require even more
>> work to rework/adjust the PMS diff.
> You need a glep here frankly; per the norm, if you want things to move
> faster, then put in time- aka, generate a patch against PMS, write a
> patch for portage, etc, you get the idea.
Since multilib-portage code is just a git branch for the portage code, i
effectively have a patch for portage. ;-)
Before i start investing more time, a question to the PM developers:
Do you prefer having everything hardcoded in PMS or can you accept
outsourcing bigger code pieces into some sort of eclass (i am thinking
about some external code base, which can be duplicated by the package
manager with internal code, but has to be used, if the external eclass
has a newer version/revision then the duplicated internal code)?
I am especially thinking about the setup of the environment and the code
details for the wrappers for binaries and headers, hardcoding those
details into PMS makes it hard to change/fix issues later on.
Gentoo Linux Developer