Re: [gentoo-dev] My wishlist for EAPI 5
On Thursday 21 June 2012 03:00:39 Ciaran McCreesh wrote: > 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... yes yes, it's very easy to throw rocks in hindsight at developers who, quite literally, were in completely new waters. not just in the Gentoo/PMS world, but in multilib *anywhere* (other distros, upstream packages, etc...). i'd say it's almost as easy as shooting fish in a barrel, but mythbusters proved that's actually kind of hard. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] My wishlist for EAPI 5
On Thursday 21 June 2012 08:11:27 Homer Parker wrote: > On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote: > > 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... > > No, but paved the way for other distros as they had nothing even close. > I'm sure you remember back then. Don't be an ass. many distros still don't. ever try Debian on ppc64 ? :) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] My wishlist for EAPI 5
On Wednesday 20 June 2012 16:25:30 Richard Yao wrote: > Multilib (and/or multiarch) support Thomas already has multilib documents put together for review. multiarch doesn't make sense for us, and even if it did, there's no way it'd be spec-ed out in a reasonable time frame for EAPI=5 (or even 6 or 7 or ...). > The current binaries cause a great deal of pain, particularly when a > user does not want to upgrade something. I had this problem with WINE > and glibc because I wanted to avoid the reverse memcpy() fiasco on my > systems. This situation would have been avoided entirely if the package > manager supported multilib. i don't buy this argument and makes me think when you say "multilib", you don't actually mean "multilib". > Automated epatch_user support > Users should be able to test patches without modifying their ebuilds. > This also saves developer time because we don't need to navigate the > portage tree (or an overlay), make a change and test it. We could just > dump the patch in the appropriate directory and build. putting forth an idea is one thing. working out the technical aspects is different. this sounds like something destined for EAPI=6: currently, epatch_user uses epatch, and that provides a lot of dynamic patch support that doesn't fit well with being spec-ed out / encoded in PMS. > Parallel make checks SGTM > POSIX Shell compliance > There has been a great deal of work done to give the user full control > of what is on his system and there is more that we can do there. In > particular, I think a lean Gentoo Linux system should be able to use > busybox sh and nothing else. That requires POSIX shell compliance. > OpenRC init scripts support this and the configure scripts support this. > The few exceptions are bugs that are addressed by the Gentoo BSD > developers. As such, I think we should make EAPI=5 use POSIX shell by > default. If an ebuild requires bash, we can allow the ebuild to declare > that (e.g. WANT_SH=bash), but that should be the exception and not the > rule. not a chance, and your logic about "choice" really makes no sense in the ebuild context. read the archives wrt Roy Maples (sadly) burning out for in- depth details as to why this is a no-go. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] My wishlist for EAPI 5
On Wednesday 20 June 2012 16:39:42 Maxim Kammerer wrote: > On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote: > > Multilib (and/or multiarch) support > > Sorry for a possibly ignorant question. Does multilib support include > the ability to build Busybox against uclibc (on a glibc system)? i'm not sure Richard knows exactly what he is asking for. multilib does not cover different C libraries, but multiarch does. the former is what Thomas has been working on (multilib portage) while the later is basically cross- compiling (use crossdev) and is unrealistic for EAPI=5 integration (and i might even say isn't really a problem anymore that needs "solving"). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 13:16 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 14:11:28 +0200 > Pacho Ramos wrote: > > Looks like you have now opted to use Brian's comment as a kind of > > "shield" of similar and discuss only about multilib, even when this > > thread was more general and we were talking to the problems shown in > > recent discussions (from forcing rebuilds issue, optional deps > > problems to some trivial questions like know where we can see what > > things are being worked out for eapi5). > > For optional deps, we're close to having two proposals. That's moving > forwards. Whether or not it will be in EAPI 5 depends solely upon > timing, and whether the Council ends up liking at least one of the two > proposals. > > For "forced rebuilds", there's a proposal already, and Zac has just > done implementation work, and most of the PMS patch was written ages > ago for kdebuild-1 and the original EAPI 3. So again, whether or not > that ends up in EAPI 5 is just a matter of timing and Council approval. > > For "what's being worked on", you just need to look at the PMS list. > > So I'm really not sure what your problem is there... > Your cynicism, that is the problem I see signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 14:16:13 +0200 Pacho Ramos wrote: > What we *also* need is to document this requirements to let people > present that work directly instead of losing days figuring out what is > needed or what not The requirement is that the PMS team needs to be able to understand the proposal, and that someone needs to do however much work is necessary (which varies massively from proposal to proposal -- multilib is at least a thousand times more complicated than adding a new function that outputs stuff based upon a use flag) to be able to present it in a form acceptable to the Council. That's all there is to it. There is no lengthy form P123b.5 to fill in or anything like that. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 14:11:28 +0200 Pacho Ramos wrote: > Looks like you have now opted to use Brian's comment as a kind of > "shield" of similar and discuss only about multilib, even when this > thread was more general and we were talking to the problems shown in > recent discussions (from forcing rebuilds issue, optional deps > problems to some trivial questions like know where we can see what > things are being worked out for eapi5). For optional deps, we're close to having two proposals. That's moving forwards. Whether or not it will be in EAPI 5 depends solely upon timing, and whether the Council ends up liking at least one of the two proposals. For "forced rebuilds", there's a proposal already, and Zac has just done implementation work, and most of the PMS patch was written ages ago for kdebuild-1 and the original EAPI 3. So again, whether or not that ends up in EAPI 5 is just a matter of timing and Council approval. For "what's being worked on", you just need to look at the PMS list. So I'm really not sure what your problem is there... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 12:59 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 13:52:24 +0200 > Peter Stuge wrote: > > Ciaran McCreesh wrote: > > > bring this to the point where we can say something other than > > > "huh?". > > > > You can accelerate by making one guess about each thing on the list > > and asking for confirmation of your guess. > > > > It sounds silly, but I realized that this actually happens all the > > time offline - at least to me. I interpret, ask if I got it right, > > then move on. It's pretty efficient, but requires both sender and > > receiver wanting successful transmission. > > The issue is not that we don't understand the list. The issue is that > we don't understand the problem (beyond superficially), how the > proposed solution works from an ebuild perspective, whether the > solution solves the problem, or how it all fits together. Most of the > stuff on the list is irrelevant from a design perspective. It's not > that the list is hard to understand, it's that understanding the > problem and solution requires completely different material. > > To take one example, figuring out exactly which variables get mangled > is an unimportant detail at this stage (and likely we'll want to > offload it to profiles, not hard-code it in PMS) and not a central part > of the proposal. > > What we need is a GLEP, describing it in high level terms with a > discussion upon how it impacts users and ebuild developers, and a PMS > patch, highlighting what's to be changed in specific technical terms. > What we *also* need is to document this requirements to let people present that work directly instead of losing days figuring out what is needed or what not signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 12:37 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 13:38:09 +0200 > Peter Stuge wrote: > > If you don't understand something of what thus far has been written, > > then why not ask specific questions to fill those gaps, and move on? > > The multilib material isn't at the point where specific questions can be > asked. Brian's description of it as an "opaque list of things" is > pretty much spot on. That's why we want a GLEP and a PMS diff -- an > attempt at those might bring this to the point where we can say > something other than "huh?". > Looks like you have now opted to use Brian's comment as a kind of "shield" of similar and discuss only about multilib, even when this thread was more general and we were talking to the problems shown in recent discussions (from forcing rebuilds issue, optional deps problems to some trivial questions like know where we can see what things are being worked out for eapi5). In all that discussions there were a clear tendency to always say "it's fine the way it's", even when a lot of people didn't even know what things were going to be included in eapi5, or discuss for days about the forcing rebuilds issue (with the, now classical, glib vs dbus-glib/g-i issue) to finally still tell people "we still didn't fully know what the problem was". I remember that, just after Brian and Zac's comments about trying to clarify things a bit on that thread and reach a solution, your reply to them was that we were missing a brilliant opportunity to "encourage developers put in a bit more work to save users a huge amount of pain here". Personally, I see a clear difference about their way to show their disagreement and yours. Of course, I know how this thread will end: once we decide to stop replying (or anybody asks us to stop) as you seem to find this happy or so and, of course, you will always say the last word, the problem will get stalled until three months later somebody else rises the problem again letting you to show again that "always rejecting position" you seem to like. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 13:52:24 +0200 Peter Stuge wrote: > Ciaran McCreesh wrote: > > bring this to the point where we can say something other than > > "huh?". > > You can accelerate by making one guess about each thing on the list > and asking for confirmation of your guess. > > It sounds silly, but I realized that this actually happens all the > time offline - at least to me. I interpret, ask if I got it right, > then move on. It's pretty efficient, but requires both sender and > receiver wanting successful transmission. The issue is not that we don't understand the list. The issue is that we don't understand the problem (beyond superficially), how the proposed solution works from an ebuild perspective, whether the solution solves the problem, or how it all fits together. Most of the stuff on the list is irrelevant from a design perspective. It's not that the list is hard to understand, it's that understanding the problem and solution requires completely different material. To take one example, figuring out exactly which variables get mangled is an unimportant detail at this stage (and likely we'll want to offload it to profiles, not hard-code it in PMS) and not a central part of the proposal. What we need is a GLEP, describing it in high level terms with a discussion upon how it impacts users and ebuild developers, and a PMS patch, highlighting what's to be changed in specific technical terms. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
Ciaran McCreesh wrote: > bring this to the point where we can say something other than "huh?". You can accelerate by making one guess about each thing on the list and asking for confirmation of your guess. It sounds silly, but I realized that this actually happens all the time offline - at least to me. I interpret, ask if I got it right, then move on. It's pretty efficient, but requires both sender and receiver wanting successful transmission. //Peter pgpTOeGyILj4n.pgp Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 13:38:09 +0200 Peter Stuge wrote: > If you don't understand something of what thus far has been written, > then why not ask specific questions to fill those gaps, and move on? The multilib material isn't at the point where specific questions can be asked. Brian's description of it as an "opaque list of things" is pretty much spot on. That's why we want a GLEP and a PMS diff -- an attempt at those might bring this to the point where we can say something other than "huh?". -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
Ciaran McCreesh wrote: > > Making constructive suggestions instead of others that can be > > easily interpreted as whims is the way to go. > > Uh huh, and that's what I've been doing the whole time when I've > been asking for a patch for PMS, a GLEP etc. .. > requests for a better description we're supposed to be looking at No, this isn't really constructive. As I wrote, try to drive the discussion by adding substance to it, rather than fueling flames by requesting others to refine. Since it is an area where you may be able to contribute, I think it would be great if you did! > are being met with complaints that we haven't magically done all > of the remaining work I think you're right that complaints are about your response, but I absolutely do not interpret the complaints to be that you personally or the PMS team did not implement the requested feature. I think that's a misunderstanding of yours. If you don't understand something of what thus far has been written, then why not ask specific questions to fill those gaps, and move on? //Peter pgpnKg4TULJ2m.pgp Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 13:05:51 +0200 Pacho Ramos wrote: > > http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml > > That shows how things can be done and how shouldn't be done, it's not > casual that you are always involved in this kind of discussions, Yes, because I'm prepared to put in the work to make sure these things get done properly, whereas others will just comment once and then ignore the rest of the thread. > instead of thinking all people is trying to "shoot the messenger", > maybe you should think about you acts here (I know it's difficult, > specially when discussions are done virtually and not in real world > where you, probably, would understand better that your way of > demanding things and putting conditions is not the way to go). Making > constructive suggestions instead of others that can be easily > interpreted as whims is the way to go. Uh huh, and that's what I've been doing the whole time when I've been asking for a patch for PMS, a GLEP etc. > > I'll remind you that for "big" features, the GLEP process is already > > documented. > > You know what I exactly mean, don't try to change the topic to "GLEP > process is already documented" to hide you don't want to put anything > of your time to help others to get proper documentation prepared to > show to pms team. Of course, you have the right to do so as this is > all contribution work that we do it if we want and have time, but > don't try to hide it in this way. That's nonsense. I've put in a lot of work on the PMS side for features that I understand. If multilib gets beyond what Brian called "a fairly opaque list of things", *then* I'm quite happy to help if I'm able. Right now, though, there's nowhere near enough that I (or as far as I can see, anyone else) can even start to go anywhere with it. This isn't going nowhere because no-one wants to help. It's going nowhere because what's been presented so far is nowhere near enough that anyone *can* help, and requests for a better description of what we're supposed to be looking at are being met with complaints that we haven't magically done all of the remaining work (which on this one I suspect is far more effort than what's been done so far). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 11:31 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 12:24:32 +0200 > Pacho Ramos wrote: > > As Peter explains, I think it is now clear enough what I was demanding > > (about clarifying what is needed to get things in next EAPI to prevent > > issues like Tommy is suffering to get multilib stuff done), but I star > > to think Ciaran thinks it's easier to simply wear a blindfold on to > > keep thinking all what he says cannot be corrected at all, neither > > improved and others must follow his instructions blindly > > Oh come on. You're just shooting the messenger. You don't like being > told that if you want something, someone needs to do the work, and you > can't just say "I want a flying unicorn!" and expect it to happen. > > I'm not the only one saying it, either. I point you to this, for > example: > > http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml That shows how things can be done and how shouldn't be done, it's not casual that you are always involved in this kind of discussions, instead of thinking all people is trying to "shoot the messenger", maybe you should think about you acts here (I know it's difficult, specially when discussions are done virtually and not in real world where you, probably, would understand better that your way of demanding things and putting conditions is not the way to go). Making constructive suggestions instead of others that can be easily interpreted as whims is the way to go. > > > Ciaran, simply think that, if PMS team agrees with a doc explaining > > what needs to be provided and the procedure, you will also save time > > and not need to follow this tedious discussions, all parts will > > benefit for sure. > > The procedure is not the important part. The important part is finding > someone who can do enough of the work that the PMS team can understand > your proposal and polish off the rough edges. The work that needs to be > done for that is very much a case by case thing, and it's not just a > simple list of steps that anyone can follow blindly. The features > you're asking for that aren't magically appearing are hard. > > I'll remind you that for "big" features, the GLEP process is already > documented. > You know what I exactly mean, don't try to change the topic to "GLEP process is already documented" to hide you don't want to put anything of your time to help others to get proper documentation prepared to show to pms team. Of course, you have the right to do so as this is all contribution work that we do it if we want and have time, but don't try to hide it in this way. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 12:24:32 +0200 Pacho Ramos wrote: > As Peter explains, I think it is now clear enough what I was demanding > (about clarifying what is needed to get things in next EAPI to prevent > issues like Tommy is suffering to get multilib stuff done), but I star > to think Ciaran thinks it's easier to simply wear a blindfold on to > keep thinking all what he says cannot be corrected at all, neither > improved and others must follow his instructions blindly Oh come on. You're just shooting the messenger. You don't like being told that if you want something, someone needs to do the work, and you can't just say "I want a flying unicorn!" and expect it to happen. I'm not the only one saying it, either. I point you to this, for example: http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml > Ciaran, simply think that, if PMS team agrees with a doc explaining > what needs to be provided and the procedure, you will also save time > and not need to follow this tedious discussions, all parts will > benefit for sure. The procedure is not the important part. The important part is finding someone who can do enough of the work that the PMS team can understand your proposal and polish off the rough edges. The work that needs to be done for that is very much a case by case thing, and it's not just a simple list of steps that anyone can follow blindly. The features you're asking for that aren't magically appearing are hard. I'll remind you that for "big" features, the GLEP process is already documented. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 12:24 +0200, Pacho Ramos escribió: > El sáb, 23-06-2012 a las 11:53 +0200, Peter Stuge escribió: > > Ciaran McCreesh wrote: > > > What is hurting is people demanding features without specifying what > > > the problem is > > > > Part of enabling progress is to show a strong will to communicate, > > with the goal of extracting common understanding from discussion. > > > > In any project based on volunteer effort you must show that you too > > are interested in giving, for anyone to give you anything. > > > > When it's not obvious that you want to receive - to the point where > > you drive the discussion (the horror!) in order to arrive at that > > point of common understanding - then people will be upset and look > > down on you, because dealing with you leaves too sour a taste behind. > > > > > > //Peter > > As Peter explains, I think it is now clear enough what I was demanding > (about clarifying what is needed to get things in next EAPI to prevent > issues like Tommy is suffering to get multilib stuff done), but I star > to think Ciaran thinks it's easier to simply wear a blindfold on to keep > thinking all what he says cannot be corrected at all, neither improved > and others must follow his instructions blindly Ciaran, simply think that, if PMS team agrees with a doc explaining what needs to be provided and the procedure, you will also save time and not need to follow this tedious discussions, all parts will benefit for sure. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 11:53 +0200, Peter Stuge escribió: > Ciaran McCreesh wrote: > > What is hurting is people demanding features without specifying what > > the problem is > > Part of enabling progress is to show a strong will to communicate, > with the goal of extracting common understanding from discussion. > > In any project based on volunteer effort you must show that you too > are interested in giving, for anyone to give you anything. > > When it's not obvious that you want to receive - to the point where > you drive the discussion (the horror!) in order to arrive at that > point of common understanding - then people will be upset and look > down on you, because dealing with you leaves too sour a taste behind. > > > //Peter As Peter explains, I think it is now clear enough what I was demanding (about clarifying what is needed to get things in next EAPI to prevent issues like Tommy is suffering to get multilib stuff done), but I star to think Ciaran thinks it's easier to simply wear a blindfold on to keep thinking all what he says cannot be corrected at all, neither improved and others must follow his instructions blindly signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
Ciaran McCreesh wrote: > What is hurting is people demanding features without specifying what > the problem is Part of enabling progress is to show a strong will to communicate, with the goal of extracting common understanding from discussion. In any project based on volunteer effort you must show that you too are interested in giving, for anyone to give you anything. When it's not obvious that you want to receive - to the point where you drive the discussion (the horror!) in order to arrive at that point of common understanding - then people will be upset and look down on you, because dealing with you leaves too sour a taste behind. //Peter pgpMq9Pj6tnx6.pgp Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 09:53:37 +0200 Pacho Ramos wrote: > Don't you see this way of handling things, with such and obscure way > of getting things accepted for every EAPI is really hurting us? What is hurting is people demanding features without specifying what the problem is, how it will be solved or what the impact on users or developers will be, and then taking up everyone's time with complaints when they don't get magical flying unicorns instantly. If you want something, you either have to do the work yourself, or find someone to do it. And here's the thing: you're assuming that "the work" is trivial, which for some of the things you're discussing it really isn't. The PMS wording is the trivial bit that comes at the end once the problem and solution have been worked out. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El jue, 21-06-2012 a las 11:27 +0200, Alec Warner escribió: > On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos 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 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. > OK thanks :) What I was trying to show is that this process is not clea
Re: [gentoo-dev] My wishlist for EAPI 5
El jue, 21-06-2012 a las 19:15 +0800, Patrick Lauer escribió: > On 06/21/12 15:25, Pacho Ramos 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 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? > No, and this is a rather random ad-hoc requirement that hasn't been > specified before. > > All previous EAPI processes went through some debate with dev-portage@ > and the other involved people (mostly pkgcore/ferringb and > paludis/ciaranm), then the proposal got handed to council to vote on, > and if council was happy that proposal was hammered into PMS and the new > EAPI published. Most of the time new features had a crude approximation > of a patch for PMS available so that the documentation updates were done > in a timely manner. > > I have no idea why Ciaran is trying to redefine the process now suddenly > and why people are taking this nonsense seriously. I take it seriously because looks like, effectively, this is blocking things. I remember when I first asked for an "easy" way of trying to allow administrator of Gentoo machines to easily handling all that needed rebuilds after updating: https://bugs.gentoo.org/show_bug.cgi?id=413619 Zac kindly pointed me to original bug: https://bugs.gentoo.org/show_bug.cgi?id=192319 I knew about that bug report but, as it was still pending after years, I thought there were technical issues making it hard to fix and, then, I tried to propose and easier solution at least until best one can be implemented. Then, if you remember the thread I opened here some weeks ago about this issue, you will see how things moved, even when Zac is already working on getting an implementation I am really worried about, even after Zac offering his work and time to get an implementation, when he offers it, Ciaran will reject it with some other excuse :( > > > 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 would say PMS team accepts what council signs off ... or am I seeing > the order wrong here? > > > So, the normal way to get a feature into the next EAPI is ... write a > specification to the best of your capabilities, present it here, when > people are done bashing it ask PMS people to help you prepare a PMS > patch so that you can suggest it to Council, and then it's mostly a > matter of waiting until the next EAPI is finalized (which currently runs > at a glacial pace of about one EAPI a year as far as I remember) > > > Take care, > > Patrick > > signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
El jue, 21-06-2012 a las 08:39 +0100, Ciaran McCreesh escribió: > On Thu, 21 Jun 2012 09:25:10 +0200 > Pacho Ramos wrote: > > 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). > > That's very much a judgement call. If a feature is "easy", low impact > and uncontroversial, you can ask for it on IRC, the mailing lists or > bugzilla, and chances are someone will do all the work for you. That cannot be the way of doing things, who is the once deciding a feature is "easy"? Is something like: https://bugs.gentoo.org/show_bug.cgi?id=357561 easy enough? Looks like it's getting so much time to get it done that we are now needing to rely on eclasses and manual removal to handle it. > If it's > a big feature with broad impact requiring lots of changes, you need to > do however much work is necessary such that a) the people working on > PMS understand it well enough to document it, b) developers understand > it well enough to know what it involves for them, c) the Council can > compare and contrast it with other proposals, and d) it can be > implemented. > > The "implement it in a package manager" thing is because of what > happened with REQUIRED_USE. It hadn't been implemented previously, and > as it turns out it has some fairly hefty usability issues. Look for example to multilib stuff, looks like mails explaining the issue and how tommy wants to fix it are not enough (I don't mean only the last thread about this problem, I remember he sending more mails explaining the issue months ago), Tommy is also providing PMS people an implementation... and now you come demanding more and more things. If all requirements would be clear from start, this shouldn't occur and all of us would save a lot of time and problems between us. > > > > > 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 reason those are still pending is because no-one knows what the > *problem* is, let alone the solution. Seriously, don't you know what are the problems of current way of handling emul packages? :O > That's not an EAPI issue, it's a > developers saying "I want a flying unicorn!" issue. > > > 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? > > I think you have a severe misunderstanding of what the EAPI process is > about here... It's not about forcing anything. The point of the EAPI > process is to allow Gentoo to roll things out without requiring > developers to rewrite all their ebuilds every few months (which > happens on Exherbo, incidentally), and without breaking user systems. > Then, I guess we could have something like GEAPI that would require only agreement between gentoo people (and people wanting to reach a consensus) that would also prevent people from needing to rewrite their ebuilds from time to time? Don't you see this way of handling things, with such and obscure way of getting things accepted for every EAPI is really hurting us? If all of us would want to reach consensus it wouldn't be so problematic but, when some people is simply waiting every proposal (even with implementation and after more tries to get it accepted) to ask them for more and more work and, when anybody ask for help to accomplish that, the same one refuses to help if he is not payed for that, this only causes Gentoo to lack some important features for ages. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, Jun 21, 2012 at 4:26 PM, Homer Parker wrote: > > In the beginning there was a method... > > And now it needs revamped.. I see no problem with re-investigating the > problem to make it better/easier/whatever. > ++ I for one am happy to have had a working amd64 system for the last decade, even if it might have been somewhat better if I had been stuck on 32-bit while the perfect system was devised. Gentoo doesn't need thrown-together hacks, but half-decent solutions that work shouldn't be held up in favor of ideal solutions that don't exist. There is always room for evolution. That said, as far as EAPIs go I'm in favor of shipping whatever is ready to ship. Rich
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 2012-06-21 at 14:20 +0100, Ciaran McCreesh wrote: > On Thu, 21 Jun 2012 08:13:50 -0500 > Homer Parker wrote: > > > And what did Gentoo get out of it? > > > > > > What I remember is Gentoo putting in lots of work randomly changing > > > things until things worked, and ending up not knowing what most of > > > those changes were or why they were done. In the beginning there was a method... > The end result is that > > > there's still a random smattering of multilib-related mess > > > cluttering up ebuild internals that doesn't actually do anything > > > except cause intermittent breakages. Doing experiments is great as > > > a way of understanding the problem, but it isn't how you deliver a > > > solution. That takes a lot more work, and someone has to be > > > prepared to do it. > > > > The hell? Other distos where still thinking of how to > > implement multilib and we had it. I know first hand as I trashed a > > system trying out the latest-n-greatest.. And the next round fixed > > it. The -emul packages from then on along with the multilib profiles > > have worked fine. > > ...so why are people running around demanding that reinventing multilib > is the number one priority and has to be in EAPI 5 immediately then? I > was under the impression that your fellow developers don't consider the > -emul packages to be an adequate solution. If that isn't the case, and > the existing mechanism is in fact fine as you claim, then great, we can > ignore multilib from an EAPI perspective. And now it needs revamped.. I see no problem with re-investigating the problem to make it better/easier/whatever. > I can only go on what your colleagues are claiming here. I suggest if > you're upset at the suggestion that Gentoo doesn't have a decent > multilib implementation then you take it up with all the people who are > demanding the PMS team provide them with one. > I can only suggest you keep track of your train of thought.. In the beginning vs now are two completely separate issues. We were first, is it surprising the method needs looked at? No. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 08:13:50 -0500 Homer Parker wrote: > > And what did Gentoo get out of it? > > > > What I remember is Gentoo putting in lots of work randomly changing > > things until things worked, and ending up not knowing what most of > > those changes were or why they were done. The end result is that > > there's still a random smattering of multilib-related mess > > cluttering up ebuild internals that doesn't actually do anything > > except cause intermittent breakages. Doing experiments is great as > > a way of understanding the problem, but it isn't how you deliver a > > solution. That takes a lot more work, and someone has to be > > prepared to do it. > > The hell? Other distos where still thinking of how to > implement multilib and we had it. I know first hand as I trashed a > system trying out the latest-n-greatest.. And the next round fixed > it. The -emul packages from then on along with the multilib profiles > have worked fine. ...so why are people running around demanding that reinventing multilib is the number one priority and has to be in EAPI 5 immediately then? I was under the impression that your fellow developers don't consider the -emul packages to be an adequate solution. If that isn't the case, and the existing mechanism is in fact fine as you claim, then great, we can ignore multilib from an EAPI perspective. I can only go on what your colleagues are claiming here. I suggest if you're upset at the suggestion that Gentoo doesn't have a decent multilib implementation then you take it up with all the people who are demanding the PMS team provide them with one. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 2012-06-21 at 13:30 +0100, Ciaran McCreesh wrote: > On Thu, 21 Jun 2012 07:11:27 -0500 > Homer Parker wrote: > > On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote: > > > 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... > > > > No, but paved the way for other distros as they had nothing > > even close. I'm sure you remember back then. Don't be an ass. > > And what did Gentoo get out of it? > > What I remember is Gentoo putting in lots of work randomly changing > things until things worked, and ending up not knowing what most of > those changes were or why they were done. The end result is that > there's still a random smattering of multilib-related mess cluttering > up ebuild internals that doesn't actually do anything except cause > intermittent breakages. Doing experiments is great as a way of > understanding the problem, but it isn't how you deliver a solution. > That takes a lot more work, and someone has to be prepared to do it. > The hell? Other distos where still thinking of how to implement multilib and we had it. I know first hand as I trashed a system trying out the latest-n-greatest.. And the next round fixed it. The -emul packages from then on along with the multilib profiles have worked fine. Again, quit being an ass. Oh, and what I remember is.. You didn't contribute. There was kingtaco, lv, and kuglafang . So you're clear there, you didn't have a damn thing to do with it. -- Homer Parker signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 07:14:49 -0500 Homer Parker wrote: > On Thu, 2012-06-21 at 09:24 +0200, justin wrote: > > Won't it be a good thing, if you instead of showing all of us, that > > you > > can tell where people fail to present something in the right way, > > help and guide them to write the necessary things like PMS patches, > > GLEPs etc., so that we can proceed in an efficient way? > > That's not his style. Never has been, and I don't see that > changing. Yeah, I'm afraid I'm not available for hire to work full time on providing basic tutoring and hand-holding on design and technical writing -- it's not really my cup of tea. But if you have the money, there are plenty of others who make their livings teaching that sort of thing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 07:11:27 -0500 Homer Parker wrote: > On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote: > > 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... > > No, but paved the way for other distros as they had nothing > even close. I'm sure you remember back then. Don't be an ass. And what did Gentoo get out of it? What I remember is Gentoo putting in lots of work randomly changing things until things worked, and ending up not knowing what most of those changes were or why they were done. The end result is that there's still a random smattering of multilib-related mess cluttering up ebuild internals that doesn't actually do anything except cause intermittent breakages. Doing experiments is great as a way of understanding the problem, but it isn't how you deliver a solution. That takes a lot more work, and someone has to be prepared to do it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 2012-06-21 at 09:24 +0200, justin wrote: > Won't it be a good thing, if you instead of showing all of us, that > you > can tell where people fail to present something in the right way, help > and guide them to write the necessary things like PMS patches, GLEPs > etc., so that we can proceed in an efficient way? That's not his style. Never has been, and I don't see that changing. -- Homer Parker signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote: > > 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... No, but paved the way for other distros as they had nothing even close. I'm sure you remember back then. Don't be an ass. -- Homer Parker signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, Jun 21, 2012 at 5:27 AM, Alec Warner wrote: > 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. > ++ Waterfall has problems even in places where people are paid to do work. It has little chance of working here. Devs aren't paid to do work. They do what interests them. So, the most effective way to make something happen is to do it yourself, or better still make it something interesting, do it yourself, and inspire others to help you out. A working program will always gather more interest than a discussion on a list. Plus Gentoo is all about choice - even if it never becomes the standard lots of people will do it anyway. Look at paludis, systemd, and so on. The autobuilt releases started out as drobbins side project on funtoo before they became the mainstream Gentoo way. Showing people that something works is always better than telling them. Rich
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 19:15:02 +0800 Patrick Lauer wrote: > > 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? > No, and this is a rather random ad-hoc requirement that hasn't been > specified before. It's dependent upon the level of complexity of the work, and whether or not anyone on the PMS team understands it enough to be able to do the work themselves. As far as I know, none of us do on this one, so it's down to whoever wants it to educate us enough that we can get it done... > All previous EAPI processes went through some debate with dev-portage@ > and the other involved people (mostly pkgcore/ferringb and > paludis/ciaranm), then the proposal got handed to council to vote on, > and if council was happy that proposal was hammered into PMS and the > new EAPI published. Most of the time new features had a crude > approximation of a patch for PMS available so that the documentation > updates were done in a timely manner. Actually, we've been passing pretty much final PMS patches to the Council to vote on. > I have no idea why Ciaran is trying to redefine the process now > suddenly and why people are taking this nonsense seriously. I'm not. > I would say PMS team accepts what council signs off ... or am I seeing > the order wrong here? The PMS team makes suggestions to the Council, and the Council accepts a subset of those. The Council can also suggest that the PMS team looks at a particular feature, but as Gentoo has no mechanism in place for forcing work to get done, that only works if there's someone with both the time and the knowledge to figure it out. > So, the normal way to get a feature into the next EAPI is ... write a > specification to the best of your capabilities, present it here, when > people are done bashing it ask PMS people to help you prepare a PMS > patch so that you can suggest it to Council Yup, and for difficult cases like the ones under discussion, a part of presenting it is to demo a working implementation on real packages so that we gain real world experience of the feature. It's also important to note that "the best of your capabilities" may not be anywhere near enough for the PMS people or the package mangler people to do the remainder of the work. > and then it's mostly a > matter of waiting until the next EAPI is finalized (which currently > runs at a glacial pace of about one EAPI a year as far as I remember) I like how you simultaneously troll both sides of that issue. Weren't you previously claiming there were too many EAPIs and that we shouldn't have lots of new ones? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On 06/21/12 15:25, Pacho Ramos 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 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? No, and this is a rather random ad-hoc requirement that hasn't been specified before. All previous EAPI processes went through some debate with dev-portage@ and the other involved people (mostly pkgcore/ferringb and paludis/ciaranm), then the proposal got handed to council to vote on, and if council was happy that proposal was hammered into PMS and the new EAPI published. Most of the time new features had a crude approximation of a patch for PMS available so that the documentation updates were done in a timely manner. I have no idea why Ciaran is trying to redefine the process now suddenly and why people are taking this nonsense seriously. > 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 would say PMS team accepts what council signs off ... or am I seeing the order wrong here? So, the normal way to get a feature into the next EAPI is ... write a specification to the best of your capabilities, present it here, when people are done bashing it ask PMS people to help you prepare a PMS patch so that you can suggest it to Council, and then it's mostly a matter of waiting until the next EAPI is finalized (which currently runs at a glacial pace of about one EAPI a year as far as I remember) Take care, Patrick
Re: [gentoo-dev] My wishlist for EAPI 5
On 21 June 2012 05:33, Alec Warner wrote: > On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao wrote: >> Here is my wishlist for EAPI 5: [...] >> POSIX Shell compliance >> There has been a great deal of work done to give the user full control >> of what is on his system and there is more that we can do there. In >> particular, I think a lean Gentoo Linux system should be able to use >> busybox sh and nothing else. That requires POSIX shell compliance. >> OpenRC init scripts support this and the configure scripts support this. >> The few exceptions are bugs that are addressed by the Gentoo BSD developers. >> As such, I think we should make EAPI=5 use POSIX shell by default. If >> an ebuild requires bash, we can allow the ebuild to declare that (e.g. >> WANT_SH=bash), but that should be the exception and not the rule. >> > > Our ebuilds are written in bash. [...] Screw > trying to get the PM to stop using bash; developers are not interested > in writing ebuilds in posix shell; bar none. > > Why would I as an ebuild author waste a bunch of time writing my > ebuild in posix compatible sh when I can use bash (and if I had a > better language than bash to write ebuilds in; I'd use that too.) You > are free to write your ebuilds in posix sh; good luck to you. Ebuilds are written in bash. And the convenience of using bash far outweighs any benefits of using posix sh instead. One needs to make a very strong case to convince enough developers to change this... -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos 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 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...
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 09:25:10 +0200 Pacho Ramos wrote: > 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). That's very much a judgement call. If a feature is "easy", low impact and uncontroversial, you can ask for it on IRC, the mailing lists or bugzilla, and chances are someone will do all the work for you. If it's a big feature with broad impact requiring lots of changes, you need to do however much work is necessary such that a) the people working on PMS understand it well enough to document it, b) developers understand it well enough to know what it involves for them, c) the Council can compare and contrast it with other proposals, and d) it can be implemented. The "implement it in a package manager" thing is because of what happened with REQUIRED_USE. It hadn't been implemented previously, and as it turns out it has some fairly hefty usability issues. > > > 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 reason those are still pending is because no-one knows what the *problem* is, let alone the solution. That's not an EAPI issue, it's a developers saying "I want a flying unicorn!" issue. > 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? I think you have a severe misunderstanding of what the EAPI process is about here... It's not about forcing anything. The point of the EAPI process is to allow Gentoo to roll things out without requiring developers to rewrite all their ebuilds every few months (which happens on Exherbo, incidentally), and without breaking user systems. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: > On Thu, 21 Jun 2012 08:08:55 +0200 > Pacho Ramos 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
Re: [gentoo-dev] My wishlist for EAPI 5
On 21/06/12 08:41, Ciaran McCreesh wrote: > On Wed, 20 Jun 2012 23:43:36 +0200 > Justin wrote: >> On 20.06.2012 22:35, Ciaran McCreesh wrote: >>> On Wed, 20 Jun 2012 16:25:30 -0400 >>> Richard Yao wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. >>> >>> This one's unlikely to happen unless someone's prepared to put in >>> the work. >> >> Tommy worked a lot on this and he asked for help to bring his >> proposal/spec/glep into shape. >> We are all aware what this is all about and know that anybody who is >> using multilib would benefit. >> Can't you simply work with him together to get it into what you expect >> it to be instead of pointing out that it isn't? > > In order to do that, it would have to get to the stage where I > understood exactly what changes are needed and why. I'm not convinced > *anyone* understands that yet. > > Writing PMS patches, at least to the level that we can review them, is > only difficult if you don't know what you want changed or why. > He wants to deprecate the app-emulation/emul-linux-x86-* packages and build it if needed directly from "normal" ebuilds through the package manager. This was stated a couple of times and is not hard to understand, even without PMS patches, GLEPS and so. *anyone* understands that there are cases when the x86 libs are needed and every gentoo package maintainer should understand, that letting the user build their own x86 libs is what we want in ideal case. There is a working implementation as a branch of portage for some time now and people work on it. So two basic things are there, the need and the idea of a working solution. This also means, that people need to have an idea of what is real problem. (And if not, it was asked a couple of times for discussion) Won't it be a good thing, if you instead of showing all of us, that you can tell where people fail to present something in the right way, help and guide them to write the necessary things like PMS patches, GLEPs etc., so that we can proceed in an efficient way? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Thu, 21 Jun 2012 08:08:55 +0200 Pacho Ramos 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... > 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. 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. 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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, 20 Jun 2012 23:43:36 +0200 Justin wrote: > On 20.06.2012 22:35, Ciaran McCreesh wrote: > > On Wed, 20 Jun 2012 16:25:30 -0400 > > Richard Yao wrote: > >> Multilib (and/or multiarch) support > >>The current binaries cause a great deal of pain, > >> particularly when a user does not want to upgrade something. I had > >> this problem with WINE and glibc because I wanted to avoid the > >> reverse memcpy() fiasco on my systems. This situation would have > >> been avoided entirely if the package manager supported multilib. > > > > This one's unlikely to happen unless someone's prepared to put in > > the work. > > Tommy worked a lot on this and he asked for help to bring his > proposal/spec/glep into shape. > We are all aware what this is all about and know that anybody who is > using multilib would benefit. > Can't you simply work with him together to get it into what you expect > it to be instead of pointing out that it isn't? In order to do that, it would have to get to the stage where I understood exactly what changes are needed and why. I'm not convinced *anyone* understands that yet. Writing PMS patches, at least to the level that we can review them, is only difficult if you don't know what you want changed or why. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El mié, 20-06-2012 a las 23:43 +0200, Justin escribió: > On 20.06.2012 22:35, Ciaran McCreesh wrote: > > On Wed, 20 Jun 2012 16:25:30 -0400 > > Richard Yao wrote: > >> Multilib (and/or multiarch) support > >>The current binaries cause a great deal of pain, particularly > >> when a user does not want to upgrade something. I had this problem > >> with WINE and glibc because I wanted to avoid the reverse memcpy() > >> fiasco on my systems. This situation would have been avoided entirely > >> if the package manager supported multilib. > > > > This one's unlikely to happen unless someone's prepared to put in the > > work. > > Tommy worked a lot on this and he asked for help to bring his > proposal/spec/glep into shape. > We are all aware what this is all about and know that anybody who is > using multilib would benefit. > Can't you simply work with him together to get it into what you expect > it to be instead of pointing out that it isn't? > 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 also don't understand why Gentoo is forced to stick with old ways of doing things until new EAPI is approved while Exherbo is free to implement and use things like that special way of handling DEPENDENCIES without waiting for any EAPI to be accepted... or maybe I am wrong and people is able to use any PM manager compliant with EAPI on exherbo without issues? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On 20.06.2012 22:35, Ciaran McCreesh wrote: > On Wed, 20 Jun 2012 16:25:30 -0400 > Richard Yao wrote: >> Multilib (and/or multiarch) support >> The current binaries cause a great deal of pain, particularly >> when a user does not want to upgrade something. I had this problem >> with WINE and glibc because I wanted to avoid the reverse memcpy() >> fiasco on my systems. This situation would have been avoided entirely >> if the package manager supported multilib. > > This one's unlikely to happen unless someone's prepared to put in the > work. Tommy worked a lot on this and he asked for help to bring his proposal/spec/glep into shape. We are all aware what this is all about and know that anybody who is using multilib would benefit. Can't you simply work with him together to get it into what you expect it to be instead of pointing out that it isn't? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 05:12 PM, Ciaran McCreesh wrote: > On Wed, 20 Jun 2012 17:05:55 -0400 Richard Yao > wrote: The multilib-portage overlay already has this working. >>> >>> But there is no spec, nor is there a developer-centric >>> description of it. > >> I missed this tibbit. I am not sure what you expect me to do this >> about this. Thomas Sachau developed the multilib overlay, he has >> put a great deal of work into it and he likely has a >> specification. > > He has something, but it's nowhere near what's needed for someone > to be able to either implement it independently or produce a PMS > patch. General consensus seems to be that it needs a GLEP and a > proposed diff against PMS before anyone can even reasonably pass > comment on it, let alone accept it. > A new EAPI implies a GLEP. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP4kIDAAoJECDuEZm+6Exk9vMP/0dP/XzzX0zifeyfHDl4wqdc RtfBbDX4C4Rm+5Ii8P/GbegDBxnZ+/SzBynx+d23mvNiAu1B5SKcAoa0dR5k2IIa IiftgPbu1nfPA9ijNcdhi6VlFbjXJVllJt3Q7BfZTu8sPrKiq0Qbi4fnpJP4OFVH XY/17GUhZy5sizpsqFIZQTggvcqVdkM99iZCey32egIhqXHM7tn8fl9StziP+dlE 4/JzkPqVCv8QojarxAGI3asQ3ysMzbVa2zRo9FGQtMi23AqiTvnakIahy6b+U5C1 holKFfTkCdp2mJAw8FHZtNeQ+DMAOSj069YTCct+fOIv6HaT5sAHYjO1ovSOkYRw VZ0SfwTlCr8dbFCpur1YbZkfBpDuhAtJq9MbQbzuqjXQXy6y2KQlHJDi7FHJCuDl 0xKlxb1nenRk1RbxWNz6Tc530G+AkwrMnqmIlEI5X1p8J6xXwDnA7I4uAUfXhnY2 Au72AeratlSIMBYuR75ocHaaFKDhK1bG0Yu1W3Kw7hwMwaEmWHLgAr4Ne/PynwUw /tck8Dl/F1vnnzR/YqY14rwC1b3tbuMdsGc2sO33sNHJw16EQTJklETV7KBhqQhf wej+MTZInbOMF0m4giyohJ+6jWaAXKQhsHo8+h1SmRY/0SLuIQPySPSI01y9Gcun PY3t9ESaVd9kZMo10trj =/oj6 -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao wrote: > Here is my wishlist for EAPI 5: > > Multilib (and/or multiarch) support > Automated epatch_user support > Parallel make checks > POSIX Shell compliance > > Here are some explanations: > > Multilib (and/or multiarch) support > The current binaries cause a great deal of pain, particularly when a > user does not want to upgrade something. I had this problem with WINE > and glibc because I wanted to avoid the reverse memcpy() fiasco on my > systems. This situation would have been avoided entirely if the package > manager supported multilib. > > Automated epatch_user support > Users should be able to test patches without modifying their ebuilds. > This also saves developer time because we don't need to navigate the > portage tree (or an overlay), make a change and test it. We could just > dump the patch in the appropriate directory and build. > > Parallel make checks > As it stands, `make check` is so slow that few people actually run it > and QA suffers as a result. We have the ability to do parallel checks, > but we need to explicitly put `emake check` into the ebuild and use > autoconf 1.12 to get that. It would be best if this behavior were the > default, not the exception. > > POSIX Shell compliance > There has been a great deal of work done to give the user full control > of what is on his system and there is more that we can do there. In > particular, I think a lean Gentoo Linux system should be able to use > busybox sh and nothing else. That requires POSIX shell compliance. > OpenRC init scripts support this and the configure scripts support this. > The few exceptions are bugs that are addressed by the Gentoo BSD developers. > As such, I think we should make EAPI=5 use POSIX shell by default. If > an ebuild requires bash, we can allow the ebuild to declare that (e.g. > WANT_SH=bash), but that should be the exception and not the rule. > Our ebuilds are written in bash. I dunno about you, but bash sucks for writing anything remotely complicated in. My goal is any script that is 200 lines of bash or more gets rewritten in something else (usually python.) I mean the canonical example here is the old python.eclass which was a masterful example of how bash can really be used to shoot yourself in the foot. However I'd argue that the opposite of what Ciaran said is true. Screw trying to get the PM to stop using bash; developers are not interested in writing ebuilds in posix shell; bar none. Why would I as an ebuild author waste a bunch of time writing my ebuild in posix compatible sh when I can use bash (and if I had a better language than bash to write ebuilds in; I'd use that too.) You are free to write your ebuilds in posix sh; good luck to you. -A
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Jun 2012 17:05:55 -0400 Richard Yao wrote: > >> The multilib-portage overlay already has this working. > > > > But there is no spec, nor is there a developer-centric description > > of it. > > I missed this tibbit. I am not sure what you expect me to do this > about this. Thomas Sachau developed the multilib overlay, he has put a > great deal of work into it and he likely has a specification. He has something, but it's nowhere near what's needed for someone to be able to either implement it independently or produce a PMS patch. General consensus seems to be that it needs a GLEP and a proposed diff against PMS before anyone can even reasonably pass comment on it, let alone accept it. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/iPKQACgkQ96zL6DUtXhG0xACfXFY/W9pck1Fl0qTR8vWWCCOC VLQAoLm0SJV42+bizP1wquNZKdKxvycF =PPkQ -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Jun 2012 17:02:10 -0400 Richard Yao wrote: > >> Lets address POSIX compliance in the ebuilds first. Then we can > >> deal with the package managers. > > > > Why? It's highly doubtful the package manglers could switch shells > > even if they wanted to, and even if every ebuild started using EAPI > > 5. It's wasted effort. > > > > Source the ebuild using the system shell, check for WANT_SH. If it > does not exist, proceed. If it does, start over with a different > shell. > > I do not see any technical problem. Package managers don't "source the ebuild"... You should take a look at the amount of horrible bash code the three PMs have, and see why it's there. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/iPC8ACgkQ96zL6DUtXhH6rQCghGeOb2N8iOm9F5u7k9jJkn2s hcwAoKLB4kSHq7KaVh9D7mllQnU3U78Z =DLvZ -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 04:54 PM, Ciaran McCreesh wrote: > On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao > wrote: >> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: >>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao >>> wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. >>> >>> This one's unlikely to happen unless someone's prepared to put >>> in the work. > >> The multilib-portage overlay already has this working. > > But there is no spec, nor is there a developer-centric description > of it. I missed this tibbit. I am not sure what you expect me to do this about this. Thomas Sachau developed the multilib overlay, he has put a great deal of work into it and he likely has a specification. You are more than welcome to talk to him about the specification. If it not well defined, feel free to share your ideas on how it could be better defined. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP4jszAAoJECDuEZm+6Exk5EMP/0xRHW2PjOzb4xIEwW2ve+qM BJNEk5lMJfL2N8x5CM30n+uUOH665fSw26o6H6mkh397F7UO+BGCctQuBgSo0q3V s+bA3yFp5mZwr326RnnNKkgY5vKNHUjd7MH568i1ARHJdCx7Epn5Ep2o95msz0XG yzfxFkKT1O5BXKYXyLeTNfHvyS6cRx4qIaq394u0iLOZbH8eIzZT4GPhy0KkPc0S yeLLULtaSLQfO+F0QF/IDBC7Dupl0nxGp5cOBfsBC8Eg+mBOEHHemmKkRqv4Cv7X kddw9bx+wjSYx0unDztyoLQ34c1XklIteOjzU+gLZtQkJ0W7+z3XQ42RwlIGPUbM dUKsYZ2rPsKjUl0gh4Gux0PyEMkokmpygqbxd8vmE1lnAJaRR4jMgcG45jv7eSLp ToGPNRVvuQUypmqkyIgVSCzBoplC4DkymS5oVy96GbNGNPypx3AhuAMpo8NwsH58 TNqetlVI9RQp2Yq4S930pSDmeqtel4G3zm6yJhmRfhpc28fnyrh7yzNwERKAqbpU rExTfGd6BJul0cirkujo9ni9OOV1ue2WjBTqhp74BsBWjse5Q9J92zWmbZ9umcu0 JNJHr3wq/Fx1E4ozoYcVIKRor7T5mj7JuZpm+cyH5/GPfPZTzb0zuJy4JqbIKqHp RfpE5eCLf16fZrB94NYz =02/m -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 04:54 PM, Ciaran McCreesh wrote: > On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao > wrote: >> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: >>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao >>> wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. >>> >>> This one's unlikely to happen unless someone's prepared to put >>> in the work. > >> The multilib-portage overlay already has this working. > > But there is no spec, nor is there a developer-centric description > of it. > >>> So far as I know, every PM relies heavily upon bash anyway >>> (and can't easily be made not to), so even if developers would >>> accept having to rewrite all their eclasses, it still wouldn't >>> remove the dep. > >> Lets address POSIX compliance in the ebuilds first. Then we can >> deal with the package managers. > > Why? It's highly doubtful the package manglers could switch shells > even if they wanted to, and even if every ebuild started using EAPI > 5. It's wasted effort. > Source the ebuild using the system shell, check for WANT_SH. If it does not exist, proceed. If it does, start over with a different shell. I do not see any technical problem. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP4jpSAAoJECDuEZm+6ExkBqgQAJjLoTfIgSUAVk6aLzC34Pkh +d7Q62a4jwZxh/XPG2WA2AoDX09JCIyr8yfdMTpayas1v7tdOP62IgG1Ovjfsb1g J3Tywf3zem6jq32ju/xfWcLn2ZVRxkHvgn0J8YLPnIWBCUUBpdGqWyNxdAbGX/94 XCD6kmAMOr1EWpk3E3SQ2C1YNN/+vLX6DWW8sFEg7TZJU/5pUTnS66LIgp0ebcte 38lYHwdZGVZBLi4ehc/RSTbFtXs4vi5Q2YW32OREyMT2oyuoSqFCH4fLczvUVzF0 SKjooI0tv7dlFcXDjkEOg7fLnHioeSVyl5q/Fgz4rcyEhJuvdJu8SmqZStS5n3q3 Dd0EJ8ntUPMKcYt6g6hSczWrsKEYGSOynM+cg0WBkaTvx/J/5JVtjfsCXU707kkj 2Z/oNpjM1XgwOfnP+LY9vsBBx0y7j+EMc0/eOO8ZDxWCVsIstTtiCUhJr2TuNpDr r2l1qVgc95JOZqGPx0/reopdM7x/8vWw+Opadg0xXZVFpvfnBlVCUH9cqFhu/DUU ygLtZgbNnIgrlykZVLL8o8kKqKauTKpAwi1SRPjY5WIdH64lt1LEGDRfoN4BkfXZ jjL5kT0tM9uEjt7SanG7EdJi2x0xZQolXdsaYOOgUOH1g35s0uuuQE69hEpe/TXP wk2bZWtEPc1wDcty1/RN =nGyi -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao wrote: > On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: > > On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao > > wrote: > >> Multilib (and/or multiarch) support The current binaries cause a > >> great deal of pain, particularly when a user does not want to > >> upgrade something. I had this problem with WINE and glibc because > >> I wanted to avoid the reverse memcpy() fiasco on my systems. This > >> situation would have been avoided entirely if the package manager > >> supported multilib. > > > > This one's unlikely to happen unless someone's prepared to put in > > the work. > > The multilib-portage overlay already has this working. But there is no spec, nor is there a developer-centric description of it. > > So far as I know, every PM relies heavily upon bash anyway (and > > can't easily be made not to), so even if developers would accept > > having to rewrite all their eclasses, it still wouldn't remove the > > dep. > > Lets address POSIX compliance in the ebuilds first. Then we can deal > with the package managers. Why? It's highly doubtful the package manglers could switch shells even if they wanted to, and even if every ebuild started using EAPI 5. It's wasted effort. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/iOG8ACgkQ96zL6DUtXhG5FgCgw3V9qz3o1d0A4TUw5y83lfCE LWkAnRbY4WKJz1xribnhUat0YL1XEwHR =dYt+ -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
On 06/20/2012 04:39 PM, Maxim Kammerer wrote: > On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote: >> Multilib (and/or multiarch) support > > Sorry for a possibly ignorant question. Does multilib support include > the ability to build Busybox against uclibc (on a glibc system)? It includes it no more than portage does currently.
Re: [gentoo-dev] My wishlist for EAPI 5
On 06/20/2012 10:25 PM, Richard Yao wrote: > Here is my wishlist for EAPI 5: > > Multilib (and/or multiarch) support > Automated epatch_user support > Parallel make checks > POSIX Shell compliance > > Here are some explanations: > > Multilib (and/or multiarch) support > The current binaries cause a great deal of pain, particularly when a > user does not want to upgrade something. I had this problem with WINE > and glibc because I wanted to avoid the reverse memcpy() fiasco on my > systems. This situation would have been avoided entirely if the package > manager supported multilib. > > Automated epatch_user support > Users should be able to test patches without modifying their ebuilds. > This also saves developer time because we don't need to navigate the > portage tree (or an overlay), make a change and test it. We could just > dump the patch in the appropriate directory and build. > > Parallel make checks > As it stands, `make check` is so slow that few people actually run it > and QA suffers as a result. We have the ability to do parallel checks, > but we need to explicitly put `emake check` into the ebuild and use > autoconf 1.12 to get that. It would be best if this behavior were the > default, not the exception. > > POSIX Shell compliance > There has been a great deal of work done to give the user full control > of what is on his system and there is more that we can do there. In > particular, I think a lean Gentoo Linux system should be able to use > busybox sh and nothing else. That requires POSIX shell compliance. > OpenRC init scripts support this and the configure scripts support this. > The few exceptions are bugs that are addressed by the Gentoo BSD developers. > As such, I think we should make EAPI=5 use POSIX shell by default. If > an ebuild requires bash, we can allow the ebuild to declare that (e.g. > WANT_SH=bash), but that should be the exception and not the rule. It is more likely to succeed either adding to busybox the missing bits of bash we use or forking bash (so eventually it could be developed on a source repo) and making it lean and fast for our specific purposes. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: > On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao > wrote: >> Multilib (and/or multiarch) support The current binaries cause a >> great deal of pain, particularly when a user does not want to >> upgrade something. I had this problem with WINE and glibc because >> I wanted to avoid the reverse memcpy() fiasco on my systems. This >> situation would have been avoided entirely if the package manager >> supported multilib. > > This one's unlikely to happen unless someone's prepared to put in > the work. The multilib-portage overlay already has this working. >> POSIX Shell compliance There has been a great deal of work done >> to give the user full control of what is on his system and there >> is more that we can do there. In particular, I think a lean >> Gentoo Linux system should be able to use busybox sh and nothing >> else. That requires POSIX shell compliance. OpenRC init scripts >> support this and the configure scripts support this. The few >> exceptions are bugs that are addressed by the Gentoo BSD >> developers. As such, I think we should make EAPI=5 use POSIX >> shell by default. If an ebuild requires bash, we can allow the >> ebuild to declare that (e.g. WANT_SH=bash), but that should be >> the exception and not the rule. > > So far as I know, every PM relies heavily upon bash anyway (and > can't easily be made not to), so even if developers would accept > having to rewrite all their eclasses, it still wouldn't remove the > dep. > Lets address POSIX compliance in the ebuilds first. Then we can deal with the package managers. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP4jeZAAoJECDuEZm+6Exkt6cP/jpDU3CQmCZlOJWHf2uLYPpg +Ft2bN2JyMs1rquIrAd0PGtMXu8zrQC5U7Q0SAO1Vm+Ieu98aHknGMPWJYtV0PpU X5/bFqk+LjaO/fFAo+x+IKET24hYXry9P27om/ZUgURKDbWvityQAeIKrZhT9U/r LzPWgSu/v9wLDBVwZpIEjlMeYMD/uA868srBDK/dVjhZHFB6bzVK8h8xhI4zq/X3 UQYPXFuCgg2s7+g/2Z+pCvGVKwX/GdGXU8ZMRtEu3PF1hgBXBXb1qkaQRQoOGsEG BRkOAp+MqI+/VClvxPFGGVfqvRZaqQhmg4VxYIELkPh4jzvfIJu/WC7CReOix574 hBhDXrPWwJ2r6Y1updNpWUg7yBQGRmAtmRd6AL4MVHG70j/6IlSrsGrQr8KrdxuP BzQDTzN0rd5iDocO3bACluzxMSrd2wk73bvaAcWYsmIVVigVASHIcdvMthgx/ctw zSEOp7sIvXejbONeIwhcqu6M6qvFi6i2o/82Mk68JXH0BAIZ2cC8atn+mmZd0SMz R49Wu9GSyNCAeubuxTxUaEatGmSGGNtXEACxGpvtyo8XbvYmfNvntsxorRvnWNXt hhIQQYQwVOsSUSCHSqKS1/lD/8EIWoMD531IRKEyhP6eMoGZBUFCrc94zoGLwmz5 VlJuFNCU9ylfbEWMayLC =I8nt -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, 20 Jun 2012 23:39:42 +0300 Maxim Kammerer wrote: > On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote: > > Multilib (and/or multiarch) support > > Sorry for a possibly ignorant question. Does multilib support include > the ability to build Busybox against uclibc (on a glibc system)? Nobody knows, since everyone you ask has a different idea of what multilib is. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote: > Multilib (and/or multiarch) support Sorry for a possibly ignorant question. Does multilib support include the ability to build Busybox against uclibc (on a glibc system)? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao wrote: > Multilib (and/or multiarch) support > The current binaries cause a great deal of pain, particularly > when a user does not want to upgrade something. I had this problem > with WINE and glibc because I wanted to avoid the reverse memcpy() > fiasco on my systems. This situation would have been avoided entirely > if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. > POSIX Shell compliance > There has been a great deal of work done to give the user > full control of what is on his system and there is more that we can > do there. In particular, I think a lean Gentoo Linux system should be > able to use busybox sh and nothing else. That requires POSIX shell > compliance. OpenRC init scripts support this and the configure > scripts support this. The few exceptions are bugs that are addressed > by the Gentoo BSD developers. As such, I think we should make EAPI=5 > use POSIX shell by default. If an ebuild requires bash, we can allow > the ebuild to declare that (e.g. WANT_SH=bash), but that should be > the exception and not the rule. So far as I know, every PM relies heavily upon bash anyway (and can't easily be made not to), so even if developers would accept having to rewrite all their eclasses, it still wouldn't remove the dep. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] My wishlist for EAPI 5
Here is my wishlist for EAPI 5: Multilib (and/or multiarch) support Automated epatch_user support Parallel make checks POSIX Shell compliance Here are some explanations: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. Automated epatch_user support Users should be able to test patches without modifying their ebuilds. This also saves developer time because we don't need to navigate the portage tree (or an overlay), make a change and test it. We could just dump the patch in the appropriate directory and build. Parallel make checks As it stands, `make check` is so slow that few people actually run it and QA suffers as a result. We have the ability to do parallel checks, but we need to explicitly put `emake check` into the ebuild and use autoconf 1.12 to get that. It would be best if this behavior were the default, not the exception. POSIX Shell compliance There has been a great deal of work done to give the user full control of what is on his system and there is more that we can do there. In particular, I think a lean Gentoo Linux system should be able to use busybox sh and nothing else. That requires POSIX shell compliance. OpenRC init scripts support this and the configure scripts support this. The few exceptions are bugs that are addressed by the Gentoo BSD developers. As such, I think we should make EAPI=5 use POSIX shell by default. If an ebuild requires bash, we can allow the ebuild to declare that (e.g. WANT_SH=bash), but that should be the exception and not the rule.
