El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: > On Thu, 21 Jun 2012 08:08:55 +0200 > Pacho Ramos <pa...@gentoo.org> 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?
signature.asc
Description: This is a digitally signed message part
