Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
> On Thu, 21 Jun 2012 08:08:55 +0200
> Pacho Ramos <pacho@g.o> wrote:
> > Also, if I remember correctly, Tommy asked for this some months ago,
> > you asked for what he sent some days ago and now you require more and
> > more work to delay things to be implemented.
>
> I still haven't seen a clear description of exactly what should be
> changed and why. I've also not seen a description of exactly what
> problem is being solved, nor a discussion of the relative merits of
> implementing a solution to whatever that problem is. All I've seen is a
> mess of code that "gets it working" in Portage (which isn't the same as
> "implements it for Portage") and a big wall of text that contains lots
> that no-one needs to know and little of what's important. This needs to
> go through the GLEP process, and it needs a PMS diff.
>
> In case you're not aware, the first time Gentoo did multilib, it was
> done as a series of random changes to Portage that no-one really
> thought through or understood. As you can see, that didn't work...
>

Then, looks clear to me that the way to get things approved in newer
EAPIs is not clear enough as looks like a lot of devs (like me) don't
know them (for example, when things to be added to EAPI need also a GLEP
and a PMS diff, also the needing to get an implementation for any
package manager). Is this documented in some place? If not, I think it
should be documented and, of course, it should be done by PMS team if
possible as they clearly know what they expect to get for approval if
needed since, I discussed some days ago, council will simply accept some
specific features to be included in next eapi once they are accepted by
PMS team. That way, we could save a lot of time, know what steps are
pending, try to ask for help for some specific steps and, finally, get
it discussed in PMS people providing all what is needed.


> > I also don't understand why Gentoo is forced to stick with old ways
> > of doing things until new EAPI is approved
>
> That's not what's going on here. The issue is that there might be one
> person who understands what "the new way of doing things", but he
> hasn't told us what he thinks that is. Once we get a proper
> explanation, getting an EAPI out doesn't take long.
>

But you must confess that old problems like multilib support, force
package rebuilding or optional dep support are still pending while still
needing and, the problem with the way things are discussed now is that
some day anybody arises the problem again, other one demands more things
to be provided, a discussion starts, the problem gets stalled... one
year later the same problem arises again. There is clearly a lack of
information to the rest of developers about how to propose anything to
get accepted for next EAPI.

> The main problem here isn't even EAPI related. Ebuild developers don't
> even know what they'll be expected, required or able to do for multilib.
>
> > while Exherbo is free to implement and use things like that special
> > way of handling DEPENDENCIES without waiting for any EAPI to be
> > accepted...
>
> The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
> have it because Portage couldn't implement it. Now it doesn't have it
> because it's too controversial to get it approved.

It was only a example, but thanks for the info :)

> Exherbo does have it
> because it was carefully discussed, compared to alternatives, planned
> out, tested, accepted by the expendable figurehead, and then rolled out.
>
> > or maybe I am wrong and people is able to use any PM manager
> > compliant with EAPI on exherbo without issues?
>
> If anyone ever manages to come up with another package mangler that can
> get close to implementing what Exherbo needs, then sure.
>

Then, you accept exherbo is not forced to *only* follow EAPI while you
force Gentoo and portage to only support features approved in an EAPI?