[gentoo-dev] Re: let's clear things up (was Slacker archs)
Steve Long wrote: Stephen P. Becker wrote: All of that said, how about we clear up all of the misinformation about how arch keywording really works, how deps get wrongly dropped, and then explain why mips has generally fallen behind. This isn't an excuse, but is merely a statement of facts which describe the situation. Thanks for the clear explanation of the process; it helps to put this in context for non-devs. Not only non-devs. Well done. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Wed, 2007-02-21 at 16:59 +, Ciaran McCreesh wrote: On Wed, 21 Feb 2007 07:31:44 +0100 Luca Barbato [EMAIL PROTECTED] wrote: | Now, I think we could wait even a bit more, but there is much interest | in seeing it complete so is natural that more people are willing to | help speeding up at least the first release. The question is not whether they are willing, but whether they are able, and whether throwing more people at it will do anything other than making it harder to coordinate. This I understand. However, your previous comments (and spb's saying he's busy with some other things) has made some people, myself included, wonder if you could possibly use some more help. We aren't talking about forcing you to take on certain people, but rather seeing if you need people, period. We can come to an agreement on who to add, if you require the help. The point being that manpower should not be the limiting factor here in getting this done when there are numerous people who are familiar enough with portage and want to to help. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 10:20:47 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: This I understand. However, your previous comments (and spb's saying he's busy with some other things) has made some people, myself included, wonder if you could possibly use some more help. We aren't talking about forcing you to take on certain people, but rather seeing if you need people, period. We can come to an agreement on who to add, if you require the help. The point being that manpower should not be the limiting factor here in getting this done when there are numerous people who are familiar enough with portage and want to to help. If the right sort of people are interested in helping, then I for one won't refuse help. However, for fairly obvious reasons I don't want to give out access willy-nilly. Any good, experienced ebuild devs with a sufficient knowledge of everything relevant and a large degree of common sense who want to help out can find me on IRC. -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Wed, 21 Feb 2007 08:28:51 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: You forgot to mention that the small group is either a subset of the interested parties or is commissioned by them. Which doesn't appear to be the case here. Given that people wouldn't be working on it if they weren't interested, it seems fairly obviously to be a subset of the interested parties. -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Wed, 21 Feb 2007 08:28:51 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: | You forgot to mention that the small group is either a subset of the | interested parties or is commissioned by them. Which doesn't appear to | be the case here. Sure it is. | Because there are a lot of people with opinions out there, and they | will all start saying things like well it would be better if things | were like $blah, so you should change it to say $blah. | | Which means exactly what it means. You would settle for something | mediocre? We are here to help you, Ciaran. No, it means the spec is a description of how things are, not how people want them to be. | Have a look at the amount of noise that comes up any time this kind | of discussion takes place on this list... | | Well, it seems that many devs believe there is something wrong in the | way PMS is conducted. Their observation isn't based on the result | itself, but on the status (or rather non-status) and behavior of some | of the project members. Some, even, question the intentions. The noise | you hear is the alarm that's ringing. It seems that some devs don't have a clue what they're on about or what's going on, and it strikes me as better that they remain uninvolved. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Wed, 21 Feb 2007 07:31:44 +0100 Luca Barbato [EMAIL PROTECTED] wrote: | Now, I think we could wait even a bit more, but there is much interest | in seeing it complete so is natural that more people are willing to | help speeding up at least the first release. The question is not whether they are willing, but whether they are able, and whether throwing more people at it will do anything other than making it harder to coordinate. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: let's clear things up (was Slacker archs)
Stephen P. Becker wrote: All of that said, how about we clear up all of the misinformation about how arch keywording really works, how deps get wrongly dropped, and then explain why mips has generally fallen behind. This isn't an excuse, but is merely a statement of facts which describe the situation. Thanks for the clear explanation of the process; it helps to put this in context for non-devs. snip loads of stuff i'm not qualified to comment on All of this has gotten us to the current situation, where ebuild maintainers are really pissed off at the mips team, and where the mips team is pissed off at ebuild developers for breaking our tree. This is why I get so mad sometimes. Anyone knows me knows that I have *consistently* screamed at people for breaking arch deps (rather than just being an asshole because I'm retiring, as a certain group seems to think). I would much rather have something that I know has been tested in the tree, rather than expend unnecessary and unavailable time to answer to every single security bug. Um not being rude, but why do you think screaming at people is a good way to work? Personally it switches me right off, and i find it hard not to flip the `bozo bit' on someone who carries on like that. Normally a day or two is sufficient for me to work out why that person was being rude to me (eg on irc ;) or at least what they were trying to say. It has never been enough for me to accept the way they said it mind; I just try to bear in mind that they have issues. Considering all that I have said above, it was no surprise that I got a bit irritated by bug #163795. However, I will say that I merely started out by saying it would have been nice for Diego to actually attempt to contact one of us on irc for a quick chat before dropping mips from all of KDE. His notoriously short fuse caused that discussion to rapidly proceed to all-out flame. I don't know either of you. What I do know is you called him a very offensive term (and saying someone is like something is just the same imo) and in the context of that discussion you were out of order. Period. TBH I don't care what discussion went on prior- imo ppl should be polite and professional. (If nothing else, it shows a real lack of imagination to resort to cuss-words. ;) In my experience when I've wanted to mouth off (not on gentoo) I've tried to make myself: read, take a break and re-read. Typically by expressing my concerns in better language, I can make my point far more effectively. snip Instead of being constructive, Diego resorted to outright preemptive harassing, which I believe to be a direct result of sour grapes from bug #163795. That would be the bug above where you called him a dick? `Sour grapes'?! I don't want to get into the whys and wherefores. I'd just like to say to all devs: PLEASE BE POLITE. It doesn't cost you anything except thinking time which will make your case _better_. I know it's hard for those of you who believe that Diego's shit smells like roses, but he was harassing an arch developer who was only trying to do his job correctly. I took exception, so I screamed at Diego as I have many other people during my time in Gentoo (yes, shocking as it may be, I have called people twats and fuckheads without them quitting as a result). And frankly that's just bad form. The fact that ppl stuck around doesn't say one iota about you or your methods; it speaks far more to their motivation. And let's face it- we all love gentoo. Or why would ciaran and you still be posting to bugs and dev-ml? Why not just fork off? Apparently that was just too much for him, so not only did he quit, but he attempted to blackmail devrel into firing me instantly. Perhaps, I should have been slightly less blunt with him, but I stand by my comments. I do not feel I was wrong to tell him off for harassing eroyf. Ah but that's not what you did, is it? If you are seriously taking the position that you stand by your rude, unprofessional manner then TBH I'm glad you're retiring, for gentoo's sake. And while I understand kloeri's statements on the blog, I don't get why you've gotten away with calling people twats and fuckheads. I can only put it down to devrel overwork. Now this is just my opinion and not fact, but Diego was merely looking for an excuse to quit, so don't blame me. I didn't force him to quit, he did that of his own free will. Anyone who knows Diego knows that he has been talking of quitting for a long time now. If not me, he would surely have found another excuse, but whatever. What is done is done. I indeed have retired, so those of you who are so upset and offended that I am still around can sleep a little easier at night knowing that Satan^H^H^H^H^HGeoman won't be screaming at you for doing stupid things any longer. Frankly I value your and ciaranm's input *when you are polite* but the rest of the time it just leaves a bad feeling in my mouth, even tho it's nothing
EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, Feb 20, 2007 at 03:11:20PM +, Steve Long wrote: Before you go- were you working on EAPI? I've been waiting ages on that.. No, that's spb's project (with apparent help from ciaranm). http://cia.navi.cx/stats/project/PMS Possible they've gone and shifted the name (or disabled notification); either way, think it's probably worth getting a status update on it in council this coming month. Honestly, way too much is riding on it being completed; some form of tracking is needed (yes it's annoying, but there are still too many arguements over is portages behaviour the standard?). ~harring pgpVUYKM0jApE.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: | On Tue, Feb 20, 2007 at 03:11:20PM +, Steve Long wrote: | Before you go- were you working on EAPI? I've been waiting ages on | that.. | | No, that's spb's project (with apparent help from ciaranm). | http://cia.navi.cx/stats/project/PMS | | Possible they've gone and shifted the name (or disabled | notification); either way, think it's probably worth getting a status | update on it in council this coming month. The offer of we'll let council people read it if they promise not to let anyone else get their hands on it is still open. However, in the interests of it ever getting finished, we have to ensure that certain people don't get their hands on it or we'll have to spend all our spare time arguing over pointless nonsense. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, Feb 20, 2007 at 03:49:56PM +, Ciaran McCreesh wrote: On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: | On Tue, Feb 20, 2007 at 03:11:20PM +, Steve Long wrote: | Before you go- were you working on EAPI? I've been waiting ages on | that.. | | No, that's spb's project (with apparent help from ciaranm). | http://cia.navi.cx/stats/project/PMS | | Possible they've gone and shifted the name (or disabled | notification); either way, think it's probably worth getting a status | update on it in council this coming month. The offer of we'll let council people read it if they promise not to let anyone else get their hands on it is still open. I can understand wait until we've got something to show; that's fairly standard- that's about the only case I consider valid however. So... how far a long are they? Further, since this *is* something gentoo needs, when will it potentially be finished? We've been told repeatedly it's being worked on, and it's referred to as if it's almost finished. In light of that, don't really see any reason for the council to *not* get a status update on it. However, in the interests of it ever getting finished, we have to ensure that certain people don't get their hands on it or we'll have to spend all our spare time arguing over pointless nonsense. What, like the existing portage devs? Flamewar aside, it's a simple request; can the council please look into it. If this is the route to go (ie, closed development and they're doing it), fine, but I'm requesting folks take a look at it, see if it's progressing. If it's not, then time to find another way to get it done. ~harring pgpFY81jVDzjh.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 08:13:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: | So... how far a long are they? Better to say what we don't have: * descriptions of all those pesky little helper programs. * clarity and detail for certain sections. | Further, since this *is* something gentoo needs, when will it | potentially be finished? We've been told repeatedly it's being | worked on, and it's referred to as if it's almost finished. It will be finished when it's ready. | However, in the interests of it ever getting finished, we have to | ensure that certain people don't get their hands on it or we'll | have to spend all our spare time arguing over pointless nonsense. | | What, like the existing portage devs? Access is open to individual people who ask for it, if we think that a) they'll be useful rather than just going around attempting to sabotage the thing and b) they won't give it to the wrong people. | Flamewar aside, it's a simple request; can the council please look | into it. If this is the route to go (ie, closed development and | they're doing it), fine, but I'm requesting folks take a look at it, | see if it's progressing. | | If it's not, then time to find another way to get it done. *shrug* It's not so much about getting it done as having something decent when it is done. For it to be useful, it has to be quality, not wiki. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: Possible they've gone and shifted the name (or disabled notification); either way, think it's probably worth getting a status update on it in council this coming month. Right now I'm placing a higher priority on getting a degree. It'll be done when it's done, which is not now. -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, Feb 20, 2007 at 05:22:59PM +, Stephen Bennett wrote: On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: Possible they've gone and shifted the name (or disabled notification); either way, think it's probably worth getting a status update on it in council this coming month. Right now I'm placing a higher priority on getting a degree. It'll be done when it's done, which is not now. Thanks for the clarification (and just to be clear, I am not being sarcastic and I do truly mean thank you for the info). Council- y'all were after getting this finished as far as I know, perhaps you could discuss intentions? ~harring pgp3Yo7MxdA7v.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Am Dienstag, 20. Februar 2007 18:33 schrieb Brian Harring: On Tue, Feb 20, 2007 at 05:22:59PM +, Stephen Bennett wrote: On Tue, 20 Feb 2007 07:24:54 -0800 Brian Harring [EMAIL PROTECTED] wrote: Possible they've gone and shifted the name (or disabled notification); either way, think it's probably worth getting a status update on it in council this coming month. Right now I'm placing a higher priority on getting a degree. It'll be done when it's done, which is not now. Council- y'all were after getting this finished as far as I know, perhaps you could discuss intentions? Why? There is work done on this, and there will be further work being done. Several council member have access to it - including me - and are quite confident about what is already done. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 10:22:14 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Perhaps not all of the council; distinctly recall diego pushing about | it though. Quick look through council logs, robbat2 was asking about | timeline also (jan. meeting specifically). You've gotta ask *why* certain people are so keen on pushing it through... Perhaps if they explained why they needed it in such a hurry we would prioritise it differently. | Several council member have access to it - including me - and | are quite confident about what is already done. | | The question was specifically in regards to timelines; completion so | that ongoing paludis vs pkgcore vs portage crap can be put to rest. *shrug* I don't see PMS as being viable until there's a fully conformant independent implementation, personally. So that more or less means that for me, PMS will become a priority at around the same time that Paludis 1.0_pre is released. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Ciaran, Admittedly, I'm new to this PMS thing so in many cases I'm speaking from a position of ignorance, but I guess I need to jump in somewhere I think that standardization is a good thing and interoperability between paludis, portage, pkgcore and others is something we should strive for. If at all possible, I think that this standardization effort should be multi-lateral in the sense that Gentoo and pkgcore are also active participants in the standardization process. Also, I don't think that the council itself needs to be involved directly, as a standards/spec project can be created and worked on, and the conformance of Portage to this standard can be measured, and if desired Portage developers can tweak portage so that it is more conformant to this standard. This can be done voluntarily by all parties, as they deem it useful. The goal would be to have the ability to measure a package manager's behavior against a known standard, rather than force a certain package manager to behave a certain way. I would expect that the general concern for interoperability within the Gentoo community will encourage package manager developers to work towards resolving any interoperability problems that do exist. I think standardization should focus on real interoperability issues, rather than esoteric technical issues. I think a good way to start would be to create some kind of test/regression suite in the portage tree that can be used to measure the package manager's functionality. Some stuff would be of an obvious pass/fail nature but other things can be couched in more subjective terms - like will unmerge device nodes - yes/no That at least would allow us to measure where we are in terms of interoperability, and identify future areas of improvement. Like I said, I'm just getting familiar with all this but those are my thoughts. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 10:22:14 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Perhaps not all of the council; distinctly recall diego pushing about | it though. Quick look through council logs, robbat2 was asking about | timeline also (jan. meeting specifically). You've gotta ask *why* certain people are so keen on pushing it through... Perhaps if they explained why they needed it in such a hurry we would prioritise it differently. | Several council member have access to it - including me - and | are quite confident about what is already done. | | The question was specifically in regards to timelines; completion so | that ongoing paludis vs pkgcore vs portage crap can be put to rest. *shrug* I don't see PMS as being viable until there's a fully conformant independent implementation, personally. So that more or less means that for me, PMS will become a priority at around the same time that Paludis 1.0_pre is released. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 12:19:12 -0700 Daniel Robbins
[EMAIL PROTECTED] wrote:
| I think that standardization is a good thing and interoperability
| between paludis, portage, pkgcore and others is something we should
| strive for. If at all possible, I think that this standardization
| effort should be multi-lateral in the sense that Gentoo and pkgcore
| are also active participants in the standardization process.
Well, Gentoo already is a participant, in that there are a number
of Gentoo developers with access to the document... At this stage, we're
deliberately keeping the numbers down because we want to get it done
rather than spend huge amounts of time arguing with the peanut gallery
(the same approach we took with eselect, the devmanual and Paludis,
rather than the approach taken with portage-ng and Zynot).
| Also, I don't think that the council itself needs to be involved
| directly, as a standards/spec project can be created and worked on,
| and the conformance of Portage to this standard can be measured, and
| if desired Portage developers can tweak portage so that it is more
| conformant to this standard. This can be done voluntarily by all
| parties, as they deem it useful.
The reason the Council is involved is because someone has to give final
approval. This won't be asked for until late on in the process.
| I think standardization should focus on real interoperability issues,
| rather than esoteric technical issues.
The esoteric technical issues are the problem, though. The areas where
there are interoperability problems are the areas where ebuilds are
doing weird things, like relying upon side effects of one
implementation of inherit or trying to manually modify vdb or assuming
that certain variables that contain directory names will not include a
trailing slash. The question is whether the ebuilds are wrong in
expecting to be able to do this, or whether package managers have to
emulate weird quirks in how Portage is currently implemented.
I'll give you a perfect example. Paludis currently includes the
following workaround:
archives = strip_trailing(archives, );
all_archives = strip_trailing(all_archives, );
The reason that this is necessary is because kde-meta.eclass does this:
[[ -n ${A/${TARBALL}/} ]] unpack ${A/${TARBALL}/}
Which means that if a package manager includes trailing spaces in ${A},
the eclass will break. Personally I consider this to be an eclass bug,
but without some standard to back it up there's no concrete answer
either way.
Another example along the same lines (this one's now fixed in the tree,
but it's a good example of weird side effect behaviour): The PHP
eclasses used to set a global scope variable called EXT_DIR based upon
the value of a variable called PHPCONFIG. The PHPCONFIG variable was
set in pkg_setup, and the EXT_DIR variable was used later on. For
Portage as it is currently implemented, this happens to be ok, because
eclasses are re-sourced for every phase. For Paludis this breaks,
because we implement the environment saving that Portage is going to do
at some point to avoid the eclass API problems.
Another example: A certain eclass we all know and love used to use
SLOT=${PVR} and then force uninstalls by overwriting VDB SLOT files
when installing packages. As it happens, Portage doesn't cache those
entries, and because of how it implements cleaning the hack happens to
work. The question is whether ebuilds are allowed to rely upon weird
quirks like that (and, indeed, whether ebuilds should be reading VDB at
all).
Another example: Various ebuilds rely upon the order of items in $A
matching the order in $SRC_URI. This one's arguably useful, but at the
same time it's questionable as to whether it works by fluke.
It's these cases that are the problem, not the generalities. On the one
hand, requiring that package managers implement every Portage quirk
identically is insane, and stops Portage from changing behaviour in the
future. On the other hand, restricting the API to only completely sane
things makes it much harder to code certain ebuilds -- the $A ordering
is one example of this.
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/
signature.asc
Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
OK, my initial impression of this is:
1) ebuilds and *especially* eclasses do way too many weird things and
can often depend on idiosyncrasies of portage. The eclass bash scripts
can be quite complex and probably 9 out of 10 (99 out of 100?) times
I'd put the burden of compatibility on the eclass rather than the
package manager, because it's the eclass that's trying to do weird
stuff.
2) to ensure cross-package-manager compatibility, all one would need
to do is document what one can and cannot assume regarding Portage
functionality. I see no harm in having the ebuilds/eclasses assume
less and encourage others to write more robust and compatible ebuild
and eclass functions.
3) I regretfully added eclasses to portage. Although they're useful, I
don't think they ever made sense from an architecture perspective and
are certainly not pretty. Eclasses are nearly ubiquitous now, which is
unfortunate. I can't remember seeing an eclass that I ever liked, even
if the functionality was really useful and everything was
well-written, thought out, documented, etc.
4) Building on 3, I think there are two ways of life in the world of
Portage - either the eclasses control you, or you fight back a bit and
control the growth of eclasses. The eclasses are sort of an
anti-architecture so I think our will should to be imposed on them
rather than the other way around. Otherwise you are in a catch-22
where we are continually adding tons of weird legacy code in the
form of eclasses and this problem of cross-package manager
compatibility will never go away.
Those are my thoughts, anyway...
If you wanted to get me to agree with you by giving me lots of eclass
compatibility issues, then it worked :)
-Daniel
On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 20 Feb 2007 12:19:12 -0700 Daniel Robbins
[EMAIL PROTECTED] wrote:
| I think that standardization is a good thing and interoperability
| between paludis, portage, pkgcore and others is something we should
| strive for. If at all possible, I think that this standardization
| effort should be multi-lateral in the sense that Gentoo and pkgcore
| are also active participants in the standardization process.
Well, Gentoo already is a participant, in that there are a number
of Gentoo developers with access to the document... At this stage, we're
deliberately keeping the numbers down because we want to get it done
rather than spend huge amounts of time arguing with the peanut gallery
(the same approach we took with eselect, the devmanual and Paludis,
rather than the approach taken with portage-ng and Zynot).
| Also, I don't think that the council itself needs to be involved
| directly, as a standards/spec project can be created and worked on,
| and the conformance of Portage to this standard can be measured, and
| if desired Portage developers can tweak portage so that it is more
| conformant to this standard. This can be done voluntarily by all
| parties, as they deem it useful.
The reason the Council is involved is because someone has to give final
approval. This won't be asked for until late on in the process.
| I think standardization should focus on real interoperability issues,
| rather than esoteric technical issues.
The esoteric technical issues are the problem, though. The areas where
there are interoperability problems are the areas where ebuilds are
doing weird things, like relying upon side effects of one
implementation of inherit or trying to manually modify vdb or assuming
that certain variables that contain directory names will not include a
trailing slash. The question is whether the ebuilds are wrong in
expecting to be able to do this, or whether package managers have to
emulate weird quirks in how Portage is currently implemented.
I'll give you a perfect example. Paludis currently includes the
following workaround:
archives = strip_trailing(archives, );
all_archives = strip_trailing(all_archives, );
The reason that this is necessary is because kde-meta.eclass does this:
[[ -n ${A/${TARBALL}/} ]] unpack ${A/${TARBALL}/}
Which means that if a package manager includes trailing spaces in ${A},
the eclass will break. Personally I consider this to be an eclass bug,
but without some standard to back it up there's no concrete answer
either way.
Another example along the same lines (this one's now fixed in the tree,
but it's a good example of weird side effect behaviour): The PHP
eclasses used to set a global scope variable called EXT_DIR based upon
the value of a variable called PHPCONFIG. The PHPCONFIG variable was
set in pkg_setup, and the EXT_DIR variable was used later on. For
Portage as it is currently implemented, this happens to be ok, because
eclasses are re-sourced for every phase. For Paludis this breaks,
because we implement the environment saving that Portage is going to do
at some point to avoid the eclass API problems.
Another example: A certain eclass we all know and love used to use
SLOT=${PVR} and then force
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 14:12:12 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: | 1) ebuilds and *especially* eclasses do way too many weird things and | can often depend on idiosyncrasies of portage. The eclass bash scripts | can be quite complex and probably 9 out of 10 (99 out of 100?) times | I'd put the burden of compatibility on the eclass rather than the | package manager, because it's the eclass that's trying to do weird | stuff. Yep. Here's the problem though: How much of the tree is it ok to modify, and how complex are the modifications allowed to be, for the sake of compatibility? The aim with Paludis is to ask for modifications only where it's a hard dried the ebuild / eclass is doing something highly stupid, simply because that's the only way it will be accepted. Even then, some maintainers refuse to make changes to code that works with one particular version of Portage. And until PMS is standardised, there's nothing that can be done to make them do otherwise. | 2) to ensure cross-package-manager compatibility, all one would need | to do is document what one can and cannot assume regarding Portage | functionality. I see no harm in having the ebuilds/eclasses assume | less and encourage others to write more robust and compatible ebuild | and eclass functions. In principle, I agree. In practice, writing robust bash code is a pain in the ass. If it's the case of a couple of lines of hacks in the package manager or a dozen lines of hacks in hundreds of ebuilds, it's simply more practical to impose a weird requirement upon the package manager. | 3) I regretfully added eclasses to portage. Although they're useful, I | don't think they ever made sense from an architecture perspective and | are certainly not pretty. Eclasses are nearly ubiquitous now, which is | unfortunate. I can't remember seeing an eclass that I ever liked, even | if the functionality was really useful and everything was | well-written, thought out, documented, etc. Eh, my objections to eclasses are purely based upon the limitations imposed by Portage (the no API change one). As a general idea they make the tree a lot less complex, and they often move all the package manager dependent hacks into one place... | If you wanted to get me to agree with you by giving me lots of eclass | compatibility issues, then it worked :) Hm. Maybe I should have picked up some of the dodgy ebuild code instead... There's a heck of a lot of that too. It's just that eclass weirdness is easier to find. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 2007-02-20 at 18:29 +, Ciaran McCreesh wrote: | The question was specifically in regards to timelines; completion so | that ongoing paludis vs pkgcore vs portage crap can be put to rest. *shrug* I don't see PMS as being viable until there's a fully conformant independent implementation, personally. So that more or less means that for me, PMS will become a priority at around the same time that Paludis 1.0_pre is released. Are you really saying that you won't be releasing this information until such time as *Paludis* meets it, even though portage/pkgcore may not? Isn't the *point* of this spec to try to bring everyone on the same page? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 16:57:50 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: | On Tue, 2007-02-20 at 18:29 +, Ciaran McCreesh wrote: | | The question was specifically in regards to timelines; completion | | so that ongoing paludis vs pkgcore vs portage crap can be put to | | rest. | | *shrug* I don't see PMS as being viable until there's a fully | conformant independent implementation, personally. So that more or | less means that for me, PMS will become a priority at around the | same time that Paludis 1.0_pre is released. | | Are you really saying that you won't be releasing this information | until such time as *Paludis* meets it, even though portage/pkgcore | may not? Isn't the *point* of this spec to try to bring everyone on | the same page? I'm saying that until there is an independent implementation, the specification is worthless and will contain huge numbers of errors. This is standard practice for professional standards, and is the principal difference between, say, Open Document Format and Office Open XML -- the former is a real standard, whereas the latter is a description of how one program operates. Now, if PMS happens to end up being ready before Paludis 1.0, PMS will get released before then. But if Paludis 1.0 ends up being ready before PMS, my and probably others' priorities will switch to getting PMS ready as quickly as sanely possible. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: This is standard practice for professional standards, and is the Now you talk about this, a standard is, in standard practice, the result of a collaborative effort of representing members of the organization(s) that is (are) supposed to adhere to said standard. I believe I don't need then to explain you how far what happens around PMS is from standard practice. You say you want to avoid endless discussions in the interest of getting it finished. Now, if your work is that good, why would there be any discussions about it? If it's not good enough, why wouldn't you let us talk about it and make it better? Also, if it goes in the wrong direction, one that Gentoo devs won't follow, what's the point in finishing it? Denis. -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 23:47:04 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: | On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: | This is standard practice for professional standards, and is the | | Now you talk about this, a standard is, in standard practice, the | result of a collaborative effort of representing members of the | organization(s) that is (are) supposed to adhere to said standard. I | believe I don't need then to explain you how far what happens around | PMS is from standard practice. You know that real standards aren't a free for all, right? They're usually written by a small group, and then commented on by interested parties when they're already well into being written. Which is exactly what we're doing... | You say you want to avoid endless discussions in the interest of | getting it finished. Now, if your work is that good, why would there | be any discussions about it? Because there are a lot of people with opinions out there, and they will all start saying things like well it would be better if things were like $blah, so you should change it to say $blah. Have a look at the amount of noise that comes up any time this kind of discussion takes place on this list... Heck, have a look at the number of people already trying to comment upon how the standard is being written without having seen it... | If it's not good enough, why wouldn't you let us talk about it and | make it better? We will let you (for values of you where your opinion is useful and relevant) discuss it when it is at an appropriate stage. | Also, if it goes in the wrong direction, one that | Gentoo devs won't follow, what's the point in finishing it? It isn't going in the wrong direction. The third parties who have access to it will tell you that. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Ciaran, Is there any way that the public can view the PMS spec that you have created so far? I am not totally familiar with how you are going about developing PMS, but based on some of your comments in this thread I'm a little bit concerned. -Daniel On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 23:47:04 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: | On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: | This is standard practice for professional standards, and is the | | Now you talk about this, a standard is, in standard practice, the | result of a collaborative effort of representing members of the | organization(s) that is (are) supposed to adhere to said standard. I | believe I don't need then to explain you how far what happens around | PMS is from standard practice. You know that real standards aren't a free for all, right? They're usually written by a small group, and then commented on by interested parties when they're already well into being written. Which is exactly what we're doing... | You say you want to avoid endless discussions in the interest of | getting it finished. Now, if your work is that good, why would there | be any discussions about it? Because there are a lot of people with opinions out there, and they will all start saying things like well it would be better if things were like $blah, so you should change it to say $blah. Have a look at the amount of noise that comes up any time this kind of discussion takes place on this list... Heck, have a look at the number of people already trying to comment upon how the standard is being written without having seen it... | If it's not good enough, why wouldn't you let us talk about it and | make it better? We will let you (for values of you where your opinion is useful and relevant) discuss it when it is at an appropriate stage. | Also, if it goes in the wrong direction, one that | Gentoo devs won't follow, what's the point in finishing it? It isn't going in the wrong direction. The third parties who have access to it will tell you that. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 17:22:07 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: | Is there any way that the public can view the PMS spec that you have | created so far? They can ask spb. If spb is convinced that they have something useful to contribute at this stage, and that they won't do something silly like sticking it where anyone can view it, he'll give them read access. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 17:22:07 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: Is there any way that the public can view the PMS spec that you have created so far? I am not totally familiar with how you are going about developing PMS, but based on some of your comments in this thread I'm a little bit concerned. At this stage, individuals can ask for a copy, or for read access to the repository, if we think that their input is likely to be more productive than distracting. Once it is sufficiently complete, read access will be opened to the public and drafts will likely be sent to -dev for comment. For the same reasons that the repository isn't public, though, such drafts are currently given out on the understanding that they won't be distributed further. -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Brian Harring wrote: [snip] In light of that, don't really see any reason for the council to *not* get a status update on it. We get status updates on it. it's pretty much it's not done, we don't want to show you every month. It's one of the things I intend to bring up at the march meeting. [snip] -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, 20 Feb 2007 18:58:48 -0800 Mike Doty [EMAIL PROTECTED] wrote: | Brian Harring wrote: | [snip] | In light of that, don't really see any reason for the council to | *not* get a status update on it. | | We get status updates on it. it's pretty much it's not done, we | don't want to show you every month. It's one of the things I intend | to bring up at the march meeting. You're ignoring our offer to show you what's done, eh? Fair enough. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Ciaran McCreesh wrote: On Tue, 20 Feb 2007 18:58:48 -0800 Mike Doty [EMAIL PROTECTED] wrote: | Brian Harring wrote: | [snip] | In light of that, don't really see any reason for the council to | *not* get a status update on it. | | We get status updates on it. it's pretty much it's not done, we | don't want to show you every month. It's one of the things I intend | to bring up at the march meeting. You're ignoring our offer to show you what's done, eh? Fair enough. I was never offered this offer. -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
Stephen Bennett wrote: At this stage, individuals can ask for a copy, or for read access to This stage is usually called early draft, the editor puts every input he deems useful in the first document and then he sends it for discussion once he is happy with it. So, no problems on this practice once we know that we are at the early draft phase of a quite large document. The perception were that the document is quite in a further stage, say pre-release, so people was expecting to see it and comment on it. Now, I think we could wait even a bit more, but there is much interest in seeing it complete so is natural that more people are willing to help speeding up at least the first release. I agree with Ciaran that would be better have at least a working sample implementation while discussing it, I won't call it 1.0pre again because it gives a wrong perception. I'm looking forward to see the spec and the initial implementation ^^ lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On Tue, Feb 20, 2007 at 07:10:51PM -0800, Mike Doty wrote: I was never offered this offer. If you read the emails by Ciaran you will see that he already offered the council members access to read the draft. -- Alexander Færøy Bugday Lead Alpha/IA64/MIPS Architecture Teams User Relations, Quality Assurance pgpA1bRB6LYYR.pgp Description: PGP signature
Re: EAPI spec (was Re: [gentoo-dev] Re: let's clear things up (was Slacker archs))
On 2/20/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: You know that real standards aren't a free for all, right? They're usually written by a small group, and then commented on by interested parties when they're already well into being written. Which is exactly what we're doing... You forgot to mention that the small group is either a subset of the interested parties or is commissioned by them. Which doesn't appear to be the case here. Because there are a lot of people with opinions out there, and they will all start saying things like well it would be better if things were like $blah, so you should change it to say $blah. Which means exactly what it means. You would settle for something mediocre? We are here to help you, Ciaran. Have a look at the amount of noise that comes up any time this kind of discussion takes place on this list... Well, it seems that many devs believe there is something wrong in the way PMS is conducted. Their observation isn't based on the result itself, but on the status (or rather non-status) and behavior of some of the project members. Some, even, question the intentions. The noise you hear is the alarm that's ringing. Denis. -- gentoo-dev@gentoo.org mailing list
