Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Alec Warner <antarus@g.o>
Subject: Re: My wishlist for EAPI 5
Date: Thu, 21 Jun 2012 11:27:10 +0200
On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos <pacho@g.o> wrote:
> 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.

I'm not following you here.

1) Usually features need a reference implementation.
2) For portage, there are like 3-5 people who know portage well enough
to write that for you.
3) You generally have to convince them to do it before you can move forward.
4) Most features never even get a reference implementation.

There is this vague idea that you can just propose something; get
consensus on the ML, everyone goes to implement it, and then it works
just as designed. That is usually called the 'waterfall' model and its
really hard to do correctly.

What I imagine the process is:

1) Submit an idea to the ML; you just need feedback (not consensus,
which is likely impossible for non-trivial ideas.)
  1.1) Your idea could be a GLEP, but I don't think a GLEP is strictly required.
2) Take feedback from step one and make an initial implementation. You
will likely find some assumptions in your 'design' from step one were
wrong, as well as other implementation issues (UI, performance, etc.)
3) Modify your idea to address the problems in 2.
4) Modify your implementation to address the problems in 2.
5) Repeat steps 2-4 a few times until you have solved all the 'big' problems.
6) Submit a diff to PMS outlining how the package manager behavior is
changed by your feature. This generally needs to be specific enough so
that other package manager authors can implement the feature.
7) Submit a devmanual patch telling users how to use the feature.

Most people fail at step two; usually because they try to get
'consensus' at step one, which is stupid and a waste of time. There
are a few hundred people on this list; we will never all agree, on
basically anything. So take the feedback people give you and do
something with it.

>
>> 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?
>

Portage can use whatever EAPIs portage wishes to publish (Zac has
published portage specific EAPIs in the past.) Generally in gentoo-x86
you can only use council approved EAPIs; so if portage was to publish
something like 'portage-1' you would have to get council approval to
use it in Gentoo-x86. It seems like a reasonable request to me, why
not talk to them about it.

The reason exherbo can 'do whatever they want' is because the project
is marketed that way. Seriously, go to Exherbo.org and look at the
'Why' section. Reason 2 is 'we need to break stuff whenever we feel it
is beneficial.' Gentoo is not marketed that way to our users. We
'generally promise' backwards compat for 6-12 months.

If we randomly added stuff to portage without being bound by EAPI then
we end up breaking stuff unintentionally all the time when rolling out
features.

-A


Replies:
Re: My wishlist for EAPI 5
-- Pacho Ramos
Re: My wishlist for EAPI 5
-- Rich Freeman
References:
My wishlist for EAPI 5
-- Richard Yao
Re: My wishlist for EAPI 5
-- Ciaran McCreesh
Re: My wishlist for EAPI 5
-- Justin
Re: My wishlist for EAPI 5
-- Pacho Ramos
Re: My wishlist for EAPI 5
-- Ciaran McCreesh
Re: My wishlist for EAPI 5
-- Pacho Ramos
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: My wishlist for EAPI 5
Next by thread:
Re: My wishlist for EAPI 5
Previous by date:
Re: Re: My wishlist for EAPI 5
Next by date:
Re: Re: Killing UEFI Secure Boot


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.