Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
(Everything here is meant to be educational, not really commenting on
anything else.)
On Thu, 2007-02-22 at 12:04 -0800, Brian Harring wrote:
> Said spec covers profiles also; mentioning at least the existance of
> the misc STAGE* settings isn't a horrible idea, even if not going into
> detail- anyone digging through the profiles will see them, and likely
> wonder why they're there, and why quite a few profiles specify an
> extra set of use lists.
Some of the stuff in profiles, such as STAGE1_USE, isn't used by the
package manager in any way. STAGE1_USE is used by nothing but catalyst,
and it does exactly what you think it does. It doesn't stack (that
might be something worth mentioning) but it is inherited.
GRP_STAGE23_USE hasn't been used in catalyst for a very long time.
Again, this was the only thing that actually used it.
Of course, I'm always willing to help anyone understand any aspects of
the profiles that might be in question. I can definitely tell you how
default-linux works. I tend to leave the hardened/embedded/uclibc stuff
alone, except where I am positive what I'm doing won't affect them
adversely.
> While writing the sucker out, I'd expect you'll come across things
> where gentoo has a specific way of doing it, which isn't required by
> the manager. The suggestion would be to track that somehow, or look
> at mangling the devmanual so that it's just diffs against the spec.
Well, the STAGE1_USE stuff you pointed out is a prime example. Also,
STAGE1_USE is *not* required. If it is empty, stage1 is built with
USE="build" and if it is actually populated, stage1 is built with
USE="build ${STAGE1_USE}".
As for USE, what I've been trying to do is the following:
default-linux - uhhh... defaults for all arches under Linux for releases
$arch - *very* generic USE additions for arch-specific stuff *only*
$relver - generic USE used to build the release... this would be the
equivalent of the old GRP_STAGE23_USE, since it is what stages 2 and 3
are built against
desktop/server - these are the massive USE that used to be in $relver
previously... since the stages aren't built against these, they can have
more stuff added to them without as harsh consequences... LiveCD-based
installs use the desktop profile for networkless installs
Essentially, as you go to the right down the stack, things get more
specific and adds more USE flags.
--
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: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
If that, what you stated in your last three paragraphs - and I do agree with it - will be the case, this proposed PMS will be dismissed and Paludis remains with a more or less accurate description, of what isn't a Gentoo package manager. Carsten pgpf4jh4lkHfG.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On 2/22/07, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: And if you want a perfect example of reverting to ad hominem rather than technical discussion, I suggest you reread your own email. I did. I don't see any ad hominem attacks. I was very careful not to say anything nasty. Even assuming I am a hypocrite - philosophically speaking, I am sure we are all hypocrites to a certain extent, yes? - this doesn't give any of us permission to behave in flagrantly nasty ways over and over again and not be called on it. That's the fallacy in your argument. At this point, I am going to separate myself from this conversation and wait to see what action is taken, if any. Really, I think you are mis-using your debating skills, as you were clearly in the wrong, and what you said was indefensible, so you should have just apologized. I tend to get pulled into these things because a) I care about Gentoo and b) I don't like to see people get away with crap over and over again by using cheap debating tricks. But I will cut myself off from this thread now. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 22:35:59 +0100 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | On Thursday 22 February 2007, Ciaran McCreesh wrote: | > On Thu, 22 Feb 2007 04:04:37 + Steve Long | > <[EMAIL PROTECTED]> wrote: | > | > I'm saying that until there is an independent implementation, | > | > the specification is worthless and will contain huge numbers of | > | > errors. | > | | > | Seriously? Without an implementation, your spec of what should | > | happen will have loads of errors? | > | > Yes. It will describe what people think is allowed, rather than what | > really is. Perfect example -- we'd never have caught the multiple | > sourcing issue without an independent implementation. | | I'm sorry, but this was already a known issue over 3 years ago. And | yes, the way portage handles ebuilds does not necessarilly win any | beauty contest. Which isn't relevant to what I said. Had it not been for the independent implementation, it would have remained "something that's been known to be weird for years", and would not have been documented or specified either way. -- 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: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thursday 22 February 2007, Ciaran McCreesh wrote: > By that same argument, anybody who ever had to deal with abuse from bug > wranglers wouldn't be using Gentoo. Which would mean a whole lot > fewer users. Grow up. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpLKVFb7JPUU.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thursday 22 February 2007, Ciaran McCreesh wrote: > On Thu, 22 Feb 2007 04:04:37 + Steve Long > > <[EMAIL PROTECTED]> wrote: > | > I'm saying that until there is an independent implementation, the > | > specification is worthless and will contain huge numbers of errors. > | > | Seriously? Without an implementation, your spec of what should happen > | will have loads of errors? > > Yes. It will describe what people think is allowed, rather than what > really is. Perfect example -- we'd never have caught the multiple > sourcing issue without an independent implementation. I'm sorry, but this was already a known issue over 3 years ago. And yes, the way portage handles ebuilds does not necessarilly win any beauty contest. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpYNgPY0OcPR.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 12:04:58 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: | Said spec covers profiles also; mentioning at least the existance of | the misc STAGE* settings isn't a horrible idea, even if not going | into detail- anyone digging through the profiles will see them, and | likely wonder why they're there, and why quite a few profiles specify | an extra set of use lists. Anything about STAGE* will be "package manager specific". The whole concept of stages is basically a workaround for Portage limitations. | While writing the sucker out, I'd expect you'll come across things | where gentoo has a specific way of doing it, which isn't required by | the manager. The suggestion would be to track that somehow, or look | at mangling the devmanual so that it's just diffs against the spec. The devmanual and PMS are two entirely different things. Think of the devmanual as "The C++ Programming Language" plus "The C++ Standard Library" and PMS as "ISO/IEC 14882:2003". -- 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: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, Feb 22, 2007 at 08:11:34PM +0100, Danny van Dyk wrote: > Am Donnerstag, 22. Februar 2007 17:41 schrieb Brian Harring: > > Further, getting away from the daft FUD we're trying to 'replace the > > ebuild format' that was leveled. > > > > > Also have a look at our statements regarding overlays again. > > > Overlays can't be configure properly. Multiple repositories can. > > > Nobody says there should be no sharing between them, but it needs > > > to be configured by the user. > > > > master_repository is a new one added within the last two weeks; > > stand corrected. > Repository defaults have been in a little bit longer I think. > > 2007-01-26 Ciaran McCreesh <[EMAIL PROTECTED]> > * doc/configuration.html.skel, > paludis/environment/default/default_config.cc, > paludis/util/collection.hh, paludis/util/collection_concrete.hh: Add > support for a repository_defaults.conf file. > > There we go. master_repository is required for thirdpartymirrors, which was the main stumbling block (and why folks were daftly copying $PORTDIR/profiles/thirdpartymirror into the overlay); feature above just enables avoiding boilerplate in the repostories/* definitions. > > SRC_URI restrictions (port, protocol, etc) are one angle of why at > > least poking them matters- really depends upon what PMS is going to > > address, standalone spec, or gentoos form- if the latter, then > > port/protocol restrictions apply, if the former then those > > restrictions need to wind up somewher as an extension of the spec. > > What has that to do with the PMS? PMS doesn't talk about how mirrors > should work or how to stage files. It's a spec for the package manager. The point there was that of binding the gentoo specific restrictions in somehow; whether y'all jam it into the spec itself (ick), or shoving it into a seperate doc. > What you are talking about are implementation details, and even those > which are only remotely related to how the package manager handles > stuff. This matters once we should ever start writing a Gentoo > Distribution Backstage Spec. Said spec covers profiles also; mentioning at least the existance of the misc STAGE* settings isn't a horrible idea, even if not going into detail- anyone digging through the profiles will see them, and likely wonder why they're there, and why quite a few profiles specify an extra set of use lists. While writing the sucker out, I'd expect you'll come across things where gentoo has a specific way of doing it, which isn't required by the manager. The suggestion would be to track that somehow, or look at mangling the devmanual so that it's just diffs against the spec. Either way, the protocol/port bit was an idle, badly phrase suggestion (in other words, take it or leave it). ~harring pgpwmM4dhSOwT.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Am Donnerstag, 22. Februar 2007 17:41 schrieb Brian Harring: > On Thu, Feb 22, 2007 at 05:07:22PM +0100, Danny van Dyk wrote: > > Am Donnerstag, 22. Februar 2007 14:26 schrieb Brian Harring: > > > On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: > > > > On Thu, 22 Feb 2007 04:04:37 + Steve Long > > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > | In process terms, I can't understand why the team working on > > > > | it isn't a pkgcore dev (eg marienz if you can't communicate > > > > | with ferringb) > > > > > > > > b) they're more interested in replacing > > > > the ebuild format > > > > > > Pure and absolute FUD; recall which project has added > > > incompatible version extensions, which is dropping running *rm > > > when reinstalling the same ver, which *still* doesn't actually > > > implement overlay logic, leading to overlay authors having to > > > copy master files into each overlay branch. > > > > Please have a look at our code before you make such claims. I meant the overlay logic, and my share of this discussion is still down the mail. Yet you discussed things I didn't even remotely mention. > Further, getting away from the daft FUD we're trying to 'replace the > ebuild format' that was leveled. > > > Also have a look at our statements regarding overlays again. > > Overlays can't be configure properly. Multiple repositories can. > > Nobody says there should be no sharing between them, but it needs > > to be configured by the user. > > master_repository is a new one added within the last two weeks; > stand corrected. Repository defaults have been in a little bit longer I think. 2007-01-26 Ciaran McCreesh <[EMAIL PROTECTED]> * doc/configuration.html.skel, paludis/environment/default/default_config.cc, paludis/util/collection.hh, paludis/util/collection_concrete.hh: Add support for a repository_defaults.conf file. There we go. > > > > And what on earth do infrastructure have to do with a package > > > > manager specification? > > > > > > Wolf31o2 (chris) is releng moreso; one of the few folks doing > > > non-trivial things with the profiles pretty much, with long term > > > experience doing so. > > > > > > In that regard, he's one of a few handful of people who basically > > > could be considered profile experts- further, he's a catalyst > > > monkey, which at least currently, is the stage building method. > > > > He said there would be no need for infrastructure to be involved; a > > claim i back. Nobody said Chris shouldn't be involved > > > > > Read again, he did not dismiss Chris, he dismissed the claim that > > Infrastructure should send somebody to discuss the package manager > > standard. > SRC_URI restrictions (port, protocol, etc) are one angle of why at > least poking them matters- really depends upon what PMS is going to > address, standalone spec, or gentoos form- if the latter, then > port/protocol restrictions apply, if the former then those > restrictions need to wind up somewher as an extension of the spec. What has that to do with the PMS? PMS doesn't talk about how mirrors should work or how to stage files. It's a spec for the package manager. What you are talking about are implementation details, and even those which are only remotely related to how the package manager handles stuff. This matters once we should ever start writing a Gentoo Distribution Backstage Spec. > Re: dismissing chris being seperate from dismissing infra, yep, > misinterpretted the phrasing- still would suggest hauling in one of > the actual profile/catalyst monkeys however since some of the stuff > they have in there aren't well documented. s/well//. And I don't think that anything or anyone speaks or spoke against Chris getting access to PMS and commenting on it. And to reiterate: this holds true for all council members. Danny -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, Feb 22, 2007 at 06:42:39PM +0100, Kevin F. Quinn wrote: > On Thu, 22 Feb 2007 17:10:38 +0100 > Marien Zwart <[EMAIL PROTECTED]> wrote: > > > The > > idea was to not get any messy portage quirks documented as required > > standard behaviour, the risk here is that we'll now get paludis quirks > > documented as required standard behaviour. > > Well, that'll come out in review later, I would expect. I'll be > surprised if the EAPI=0 spec Ciaran et. al. are working on just gets > rubber-stamped without anyone looking! This thread shows there are a > number of people who know what they're talking about and will review it > heavily when it is published as a draft, and the council are unlikely > to approve something that doesn't have broad support. I'd like to add some emphasis on "when it is published as a draft". What makes me uncomfortable is that the intention seems to be to release that draft simultaneously with the Paludis 1.0_pre mentioned earlier, which is rather a lot later than I'd like to see it. > With respect to having a small relatively closed group for initial > drafting - it's a sensible way to do things in the early stages (it's > not the only sensible way of course). In the early stages: agreed. I just hope it will not be developed up to "release candidate" status with little external (from non-Paludis devs) input. > If anyone doesn't like it, > there's nothing stopping them from drafting their own in a different > way. Indeed, having two strong drafts would be good, for finding > idiosyncrasies from different perspectives. If I considered myself qualified and had a lot of spare time I would have started doing that by now :) > I have to say, the few queries I've seen from Ciaran have been exactly > what I would (happily) expect. Yes, the *few* queries I've seen were ok. Perhaps there is simply much less there yet than I think there is. -- Marien. pgpq4paBtpv9u.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 17:10:38 +0100 Marien Zwart <[EMAIL PROTECTED]> wrote: > I am a bit unsure about what the goal for PMS is here. It does not > seem to be to document what a certain (the current?) version of > portage does, as the defacto standard. Instead you want to document > what portages *intention* is, or something like that. That obviously > sounds like an excellent idea, but as far as I know most of the PMS > contributors are also Paludis devs. Paludis, being an alternative to > portage, is *also* trying to handle ebuilds the way portage is > "intended" to handle them. So what I'm afraid of is that "by the time > that Paludis 1.0_pre is released" we will simultaneously see PMS > released to the public, and Paludis 1.0_pre supporting that PMS > perfectly, with all deviations on the part of portage (or pkgcore) > being considered "bugs" in their implementation of the specification. The intention is much as you initially surmised -- to describe portage's intended behaviour, or perhaps more accurately that subset of Portage's current behaviour which ebuilds and eclasses upon which are allowed to rely. Certainly by the time it is finished and sent to the Council for approval I expect whatever is the current Portage release to be compatible, and in most cases where I've deviated thus far from what Portage allows or does I've asked the current portage team whether it seems reasonable to do so. In some cases there are ebuilds in the tree relying upon behaviour that is not specified by PMS, or intended to be. These are the cases where only one or two packages rely upon undocumented and often unintentional by-products of Portage behaviour, and it seems more sensible to fix those few ebuilds instead of adding a lot of compatibility junk to the standard. A good example of this would be the recent -dev thread on global ebuild variables and pkg_setup. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 17:10:38 +0100 Marien Zwart <[EMAIL PROTECTED]> wrote: | I am a bit unsure about what the goal for PMS is here. It does not | seem to be to document what a certain (the current?) version of | portage does, as the defacto standard. Instead you want to document | what portages *intention* is, or something like that. The aim is to document things that Portage does intentionally, along with things that Portage does unintentionally if that behaviour is required by a lot of the tree, whilst excluding things that are clearly Portage bugs. Which is, of course, not entirely quantifiable, rather vague and a pain in the ass to get right, which is another reason that it helps that everyone currently writing PMS is more or less on the same page in terms of what gets documented. -- 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: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 05:26:56 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: | > | Seriously? Without an implementation, your spec of what should | > | happen will have loads of errors? | > | > Yes. It will describe what people think is allowed, rather than what | > really is. | | If you're writing the spec to match what "people think", why limit | the # of folks involved? You're reading that backwards. | > b) they're more interested in replacing | > the ebuild format | | Pure and absolute FUD; recall which project has added incompatible | version extensions Which are optional | which is dropping running *rm when reinstalling the same ver We haven't done that in trunk/ for a while now. | which *still* doesn't actually implement overlay logic, Sure we do. | leading to overlay authors having to copy master files into each | overlay branch. Uh, no. | Doing it formally, I hereby request access to PMS specifically with | the intention of going over it to spot where it differs from long | standing portage behaviour. And as you know all too well, given your behaviour on every previous discussion we've had related to this, you're not getting it. | > | a portage dev such as zmedico | > | > We have a Portage dev reviewing it. | | Which, if I may ask? (vague specifics help no one). Zmedico, | indicated above isn't (although perhaps you're just being coy, and he | is). Genone isn't ever around, bit hard for him to be doing it. | Stubbs is mia, kito/exg are both MIA afaik (additionally, prefix | specific although both have a pretty good understanding of env | requirements due to changing it for the prefix experiment- same goes | for grobian despite not being an official portage monkey). | | That leaves spanky, and antarus, who you specifically contradict | within the email. | | So... which? Genone. | > > and Gianelloni for the infrastructure. | > | > And what on earth do infrastructure have to do with a package | > manager specification? | | Wolf31o2 (chris) is releng moreso; one of the few folks doing | non-trivial things with the profiles pretty much, with long term | experience doing so. | | In that regard, he's one of a few handful of people who basically | could be considered profile experts- further, he's a catalyst monkey, | which at least currently, is the stage building method. Which I know fine well, and which has no relevance to what I said. | For example, dismissing Chris when he's effectively the "profiles | guy". Granted, can involve him afterwards, but don't much see the | point in *not* doing it up front. Just where did I dismiss Chris? -- 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: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 17:10:38 +0100 Marien Zwart <[EMAIL PROTECTED]> wrote: > The > idea was to not get any messy portage quirks documented as required > standard behaviour, the risk here is that we'll now get paludis quirks > documented as required standard behaviour. Well, that'll come out in review later, I would expect. I'll be surprised if the EAPI=0 spec Ciaran et. al. are working on just gets rubber-stamped without anyone looking! This thread shows there are a number of people who know what they're talking about and will review it heavily when it is published as a draft, and the council are unlikely to approve something that doesn't have broad support. With respect to having a small relatively closed group for initial drafting - it's a sensible way to do things in the early stages (it's not the only sensible way of course). If anyone doesn't like it, there's nothing stopping them from drafting their own in a different way. Indeed, having two strong drafts would be good, for finding idiosyncrasies from different perspectives. I have to say, the few queries I've seen from Ciaran have been exactly what I would (happily) expect. Queries about whether some current portage behaviours should be classed as quirks or EAPI=0 behaviour, presumably because the answer has a large impact on the design of a package manager. A good example is the recent one about whether EAPI=0 should require that the ebuild be sourced in every phase or only once. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 01:42:47 -0700 "Daniel Robbins" <[EMAIL PROTECTED]> wrote: | Also, talk about derailing Paludis - *your behavior* is what's | derailing the future of Paludis and making people uncomfortable with | your solo development style. I will not use Paludis, contribute to it, | or suggest that others use it simply because I don't like how you find | it so easy to shamelessly berate other people. By that same argument, anybody who ever had to deal with abuse from bug wranglers wouldn't be using Gentoo. Which would mean a whole lot fewer users. | To have a successful open source project, you need to be at least | somewhat successful at getting along with people. You at least need to | try. You are not trying. Oh, I get along with most people just fine. And if you want a perfect example of reverting to ad hominem rather than technical discussion, I suggest you reread your own email. -- 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: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, Feb 22, 2007 at 05:07:22PM +0100, Danny van Dyk wrote: > Am Donnerstag, 22. Februar 2007 14:26 schrieb Brian Harring: > > On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: > > > On Thu, 22 Feb 2007 04:04:37 + Steve Long > > > <[EMAIL PROTECTED]> wrote: > > > | In process terms, I can't understand why the team working on it > > > | isn't a pkgcore dev (eg marienz if you can't communicate with > > > | ferringb) > > > b) they're more interested in replacing > > > the ebuild format > > > > Pure and absolute FUD; recall which project has added incompatible > > version extensions, which is dropping running *rm when reinstalling > > the same ver, which *still* doesn't actually implement overlay logic, > > leading to overlay authors having to copy master files into each > > overlay branch. > > Please have a look at our code before you make such claims. Did. same cpv reinstall issue with *rm still is there. Incompatible version extension (-scm) is indisputable, and still is there. Other comments, such as not exporting SLOT still stand; one additional is not exporting the use conditional collapsed form of RESTRICT (yes, it supports use conditionals and must be exported). Those *are* changes to the format; the statements stand. Further, getting away from the daft FUD we're trying to 'replace the ebuild format' that was leveled. > Also have a look at our statements regarding overlays again. Overlays > can't be configure properly. Multiple repositories can. Nobody says > there should be no sharing between them, but it needs to be configured > by the user. master_repository is a new one added within the last two weeks; stand corrected. > > > And what on earth do infrastructure have to do with a package > > > manager specification? > > > > Wolf31o2 (chris) is releng moreso; one of the few folks doing > > non-trivial things with the profiles pretty much, with long term > > experience doing so. > > > > In that regard, he's one of a few handful of people who basically > > could be considered profile experts- further, he's a catalyst monkey, > > which at least currently, is the stage building method. > > He said there would be no need for infrastructure to be involved; a > claim i back. Nobody said Chris shouldn't be involved > Read again, he did not dismiss Chris, he dismissed the claim that > Infrastructure should send somebody to discuss the package manager > standard. SRC_URI restrictions (port, protocol, etc) are one angle of why at least poking them matters- really depends upon what PMS is going to address, standalone spec, or gentoos form- if the latter, then port/protocol restrictions apply, if the former then those restrictions need to wind up somewher as an extension of the spec. Re: dismissing chris being seperate from dismissing infra, yep, misinterpretted the phrasing- still would suggest hauling in one of the actual profile/catalyst monkeys however since some of the stuff they have in there aren't well documented. ~harring pgpdS0QlutzWW.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: > On Thu, 22 Feb 2007 04:04:37 + Steve Long > <[EMAIL PROTECTED]> wrote: > | In process terms, I can't understand why the team working on it isn't > | a pkgcore dev (eg marienz if you can't communicate with ferringb) > > Because a) they haven't asked, Since I'm a relatively active pkgcore dev and listed explicitly in the text you reply to, I'm going to assume I'm part of the "they" here. I have not asked for access to PMS. The whole process of "only people we deem sufficiently skilled get access" makes me a bit uncomfortable. For example, what if I managed to get through whatever process there is for verifying if I'm capable of contributing, and then am unable to actually contribute because of time constraints? I'm afraid that would effectively reduce my "credit" for participating in future projects of the same kind. That's sort of a worst case scenario though. And it's likely I do lack the knowledge and experience to contribute a lot to this specification, but that is a bit hard for me to judge without being able to see what is there already in the first place. > b) they're more interested in replacing the ebuild format I am very curious where you got that idea. No, I am not interested in replacing the ebuild format. Nor is any other pkgcore dev as far as I know. I do have a few ideas for extensions to the format, which work together with the EAPI proposal. > c) every other time they've gotten involved they've been highly > unhelpful. Do you have any examples in mind here? I can't think of one, I'm curious what project you are referring to. No longer in reply to this particular mail, but to the thread in general: I am a bit unsure about what the goal for PMS is here. It does not seem to be to document what a certain (the current?) version of portage does, as the defacto standard. Instead you want to document what portages *intention* is, or something like that. That obviously sounds like an excellent idea, but as far as I know most of the PMS contributors are also Paludis devs. Paludis, being an alternative to portage, is *also* trying to handle ebuilds the way portage is "intended" to handle them. So what I'm afraid of is that "by the time that Paludis 1.0_pre is released" we will simultaneously see PMS released to the public, and Paludis 1.0_pre supporting that PMS perfectly, with all deviations on the part of portage (or pkgcore) being considered "bugs" in their implementation of the specification. This does not go into just how far PMS might end up deviating from existing portage behaviour and existing ebuilds in the tree, and how much of that is acceptable for a specification that is intended to be picked up by the council as something official all ebuilds and managers must adhere to. We have already seen some examples where code used in ebuilds currently in the tree would be invalid under the new specification. It does not seem right to me to have a specification like this (which if it gets picked up by the council all tree ebuilds and all package managers should comply with) written mostly by developers of a single package manager (no pkgcore devs have access to the PMS spec at the moment. I do not know who *does* have access though. Is there a list somewhere, or do you need to have access to get at the list? :) ). Most of this could be countered by saying that there should be a "reference package manager" to go along with the specification, but I am not convinced this is the right approach here, since a reason to write this specification to begin with was to be able to figure out which of the package managers are viable portage alternatives. The idea was to not get any messy portage quirks documented as required standard behaviour, the risk here is that we'll now get paludis quirks documented as required standard behaviour. -- Marien. pgpL3ElYSvXzs.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Am Donnerstag, 22. Februar 2007 14:26 schrieb Brian Harring: > On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: > > On Thu, 22 Feb 2007 04:04:37 + Steve Long > > > > <[EMAIL PROTECTED]> wrote: > > | > I'm saying that until there is an independent implementation, > > | > the specification is worthless and will contain huge numbers of > > | > errors. > > | > > | Seriously? Without an implementation, your spec of what should > > | happen will have loads of errors? > > > > Yes. It will describe what people think is allowed, rather than > > what really is. > [snip] > > Perfect example -- we'd never have caught the multiple > > sourcing issue without an independent implementation. > > That issue was caught long ago by the portage branch of ebd (now > known as pkgcore) actually, portage-2.1_alpha20050718 being the > specific released version (rest where unofficial tarballs). Tree has > degraded a bit since then, but already went after the issue a long > while back to try and get things cleaned. > > I'm well aware thats going to be read "nya nya, we saw it first"; > that's not the intention. Intention is to point out that y'all are > basically covering territory others may already have, thus > potentially making the same mistakes others did. Re: env save/reload > mistakes, will address it in a seperate email within next day or so > (need to write it mainly). > > > | In process terms, I can't understand why the team working on it > > | isn't a pkgcore dev (eg marienz if you can't communicate with > > | ferringb) > > > > > b) they're more interested in replacing > > the ebuild format > > Pure and absolute FUD; recall which project has added incompatible > version extensions, which is dropping running *rm when reinstalling > the same ver, which *still* doesn't actually implement overlay logic, > leading to overlay authors having to copy master files into each > overlay branch. Please have a look at our code before you make such claims. Also have a look at our statements regarding overlays again. Overlays can't be configure properly. Multiple repositories can. Nobody says there should be no sharing between them, but it needs to be configured by the user. > Not intending on bashing, point is, pkgcore has *never* pushed > "replacing the ebuild format", nor realistically changes to the > ebuild/repo/configuration formats; implying otherwise is indicative > of one being out of touch with reality. > > > Because a) they haven't asked, > > Oddly enough, asked. Got the "we give access to those who are > useful" response several time over. Bringing up the issue, generally > seems to trigger that response. > > > and c) every other time they've gotten involved > > they've been highly unhelpful. > > > And what on earth do infrastructure have to do with a package > > manager specification? > > Wolf31o2 (chris) is releng moreso; one of the few folks doing > non-trivial things with the profiles pretty much, with long term > experience doing so. > > In that regard, he's one of a few handful of people who basically > could be considered profile experts- further, he's a catalyst monkey, > which at least currently, is the stage building method. He said there would be no need for infrastructure to be involved; a claim i back. Nobody said Chris shouldn't be involved, and further more as Chris is a council member he has the opportunity for read-only access or a copy of the PMS repository under the prerequsite that it will not be shared until it's finished. Both kloeri and I have taken this opportunity and we told the other council members in one of the meetings. > > Somehow I don't think you have the slightest clue what the scope of > > the document is... > > The suggetions he's laying out is intended to get multiple folks > involved who each have their own specialized domain knowledge. > > For example, dismissing Chris when he's effectively the "profiles > guy". Granted, can involve him afterwards, but don't much see the > point in *not* doing it up front. Read again, he did not dismiss Chris, he dismissed the claim that Infrastructure should send somebody to discuss the package manager standard. Danny -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Wed, 2007-02-21 at 21:33 -0800, antarus wrote: > I think the whole deal is blown out of proportion, mostly because many > people dislike Ciaran, and unfortunately Ciaran dislikes (or distrusts, > may be a better word) many other people (myself and Brian Harring > included). If the aim is to get everyone to work together to make a big > happy spec; I just don't see it happening (the teams really don't get > along well when discussing technical issues). The only potential issue > is that PMS comes out and the aforementioned 'meddlers' make their > statements and it is a situation that is beyond reconcilliation. You've > basically written a PMS that may never get approved just because we will > never agree on a standard anyway (due to specific differences in how we > view a PM working). > > In essence, delaying all the confrontation to the end. Which is cool > with me; tbh ;) If I'm not mistaken, the PMS will be something the Council will eventually agree on and set in some form of soft stone. If this is the case, then all the posturing and complaining in the world won't make much different. The council would be the deciding factor. Of course, we're not blind. We'll see the discussion. However, there comes a point when a discussion is nothing more than bitter conflict between two parties, where each is simply repeating themselves. I've been privy to a few of these, and admittedly, participated in a few. The end goal is to come up with a spec that everyone adheres to. Nothing says the spec cannot be amended. The point is that at some point, we have to agree on *something* or we never move forward. Does it have to be perfect? No. But we should try our best to make it as close to perfect as we can before we try forcing the differing implementations to use it. -- 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: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 2007-02-22 at 04:13 +, Ciaran McCreesh wrote: > | and Gianelloni for the infrastructure. > > And what on earth do infrastructure have to do with a package manager > specification? Especially considering that I am not an infrastructure guy. I'll be honest. I'm not concerned personally with the *contents* of the package manager specification, since I know it will end up being reviewed by many. What I am mostly concerned with is making sure that we're moving forward as efficiently as possible. I want this spec so we can all get cracking on making everything support it. The contents itself I leave to more capable hands. I'll be reviewing it when it is released, but that's only just to assist in the process. -- 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: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 13:18:13 +0100 "Ioannis Aslanidis" <[EMAIL PROTECTED]> wrote: > > As for Ciaran bashing Jakub, I can't help but nod (and gasp at > > some of Jakub's comments) - for quite some time now. > > Bashing on someone is always wrong. > Bashing on someone gets you banned. Tell that to Jakub. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Brian Harring wrote: | Seriously? Without an implementation, your spec of what should happen | will have loads of errors? Yes. It will describe what people think is allowed, rather than what really is. > Don't think so; making the point that if attempting to write the spec > to target what 'people think'... that's rather subjective, and it's > easy for a subgroup of people to get ideas that don't match what > others think. > > Possible I'm being too literal, if so feel free to correct me. Ok, try this. Yes. [Without an implementation] It [the spec] will describe what people think is allowed, rather than what really is [allowed]. That is how I understood Ciaran's comment. Which means you compleatly inverted it. Regards signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, Feb 22, 2007 at 02:43:57PM +0100, Thomas R??sner wrote: > Brian Harring schrieb: > >On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: > > > >>On Thu, 22 Feb 2007 04:04:37 + Steve Long > >><[EMAIL PROTECTED]> wrote: > >>| > I'm saying that until there is an independent implementation, the > >>| > specification is worthless and will contain huge numbers of errors. > >>| > >>| Seriously? Without an implementation, your spec of what should happen > >>| will have loads of errors? > >> > >>Yes. It will describe what people think is allowed, rather than what > >>really is. > >> > > > >If you're writing the spec to match what "people think", why limit the > ># of folks involved? > > Uhm, I think you completely inverted what Ciaran meant. Don't think so; making the point that if attempting to write the spec to target what 'people think'... that's rather subjective, and it's easy for a subgroup of people to get ideas that don't match what others think. Possible I'm being too literal, if so feel free to correct me. ~harring pgpfI1dtBbf7y.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Brian Harring schrieb: On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: On Thu, 22 Feb 2007 04:04:37 + Steve Long <[EMAIL PROTECTED]> wrote: | > I'm saying that until there is an independent implementation, the | > specification is worthless and will contain huge numbers of errors. | | Seriously? Without an implementation, your spec of what should happen | will have loads of errors? Yes. It will describe what people think is allowed, rather than what really is. If you're writing the spec to match what "people think", why limit the # of folks involved? Uhm, I think you completely inverted what Ciaran meant. Regards, Thomas (watching from the peanut gallery) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: > On Thu, 22 Feb 2007 04:04:37 + Steve Long > <[EMAIL PROTECTED]> wrote: > | > I'm saying that until there is an independent implementation, the > | > specification is worthless and will contain huge numbers of errors. > | > | Seriously? Without an implementation, your spec of what should happen > | will have loads of errors? > > Yes. It will describe what people think is allowed, rather than what > really is. If you're writing the spec to match what "people think", why limit the # of folks involved? If you've just involved paludis devs, you're limiting the "what people think" to "what paludis folk think". Not saying thats the case (I'd assume y'all have at least a few non paludis people commenting). Regardless, my longstanding view on the matter is that eapi=0 must be "what it really is", ie, it should document the long term behaviour of portage up to the point of breaking the specification out of portage. Lots of folks have lots of goofy ideas about what the manager does (see the old gnome/metadata constant wars if in doubt), that doesn't mean those views are right- nor are they particularly useful if the intention is to document the format (wishlists should be reserved for revisions of the format, not documenting the existing). Mind you, changes within limits are fine- good example is atom inconsistancy (bug 152127). That said, the change there was done up front, rather then stating "this is how it should be". Talking point wise, it would be good to get an idea of some of the "what people think is allowed, rather than what really is". > Perfect example -- we'd never have caught the multiple > sourcing issue without an independent implementation. That issue was caught long ago by the portage branch of ebd (now known as pkgcore) actually, portage-2.1_alpha20050718 being the specific released version (rest where unofficial tarballs). Tree has degraded a bit since then, but already went after the issue a long while back to try and get things cleaned. I'm well aware thats going to be read "nya nya, we saw it first"; that's not the intention. Intention is to point out that y'all are basically covering territory others may already have, thus potentially making the same mistakes others did. Re: env save/reload mistakes, will address it in a seperate email within next day or so (need to write it mainly). > | In process terms, I can't understand why the team working on it isn't > | a pkgcore dev (eg marienz if you can't communicate with ferringb) > > b) they're more interested in replacing > the ebuild format Pure and absolute FUD; recall which project has added incompatible version extensions, which is dropping running *rm when reinstalling the same ver, which *still* doesn't actually implement overlay logic, leading to overlay authors having to copy master files into each overlay branch. Not intending on bashing, point is, pkgcore has *never* pushed "replacing the ebuild format", nor realistically changes to the ebuild/repo/configuration formats; implying otherwise is indicative of one being out of touch with reality. > Because a) they haven't asked, Oddly enough, asked. Got the "we give access to those who are useful" response several time over. Bringing up the issue, generally seems to trigger that response. > and c) every other time they've gotten involved > they've been highly unhelpful. Specifics would be welcome. I'll remind you, despite y'all coining my last name as verbage for 'troll', I've spent the time going over paludis's differing implementation pointing out the format incompatibilities, decent number of which y'all fixed after a bit of the usual warring. Doing it formally, I hereby request access to PMS specifically with the intention of going over it to spot where it differs from long standing portage behaviour. May view that as unhelpful to do now, but as spb and others have stated, can't extend the format without documenting what it is *now*. > | a portage dev such as zmedico > > We have a Portage dev reviewing it. Which, if I may ask? (vague specifics help no one). Zmedico, indicated above isn't (although perhaps you're just being coy, and he is). Genone isn't ever around, bit hard for him to be doing it. Stubbs is mia, kito/exg are both MIA afaik (additionally, prefix specific although both have a pretty good understanding of env requirements due to changing it for the prefix experiment- same goes for grobian despite not being an official portage monkey). That leaves spanky, and antarus, who you specifically contradict within the email. So... which? > > and Gianelloni for the infrastructure. > > And what on earth do infrastructure have to do with a package manager > specification? Wolf31o2 (chris) is releng moreso; one of the few folks doing non-trivial things with the profiles pretty much, with long term experience doing so. I
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
As for Ciaran bashing Jakub, I can't help but nod (and gasp at some of Jakub's comments) - for quite some time now. Bashing on someone is always wrong. Bashing on someone gets you banned. -- Ioannis Aslanidis 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Wed, 21 Feb 2007 21:48:49 -0700 "Daniel Robbins" <[EMAIL PROTECTED]> wrote: > On 2/21/07, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > Are you insane? What on earth could Jakub possibly contribute? If > > you want a rough indication of Jakub's level of ebuild > > understanding, take a look at bug 160328. > > Is there any process in place to ban people from the gentoo-dev > mailing list who are chronically verbally abusive and make no effort > at all to be polite? > > We shouldn't have to put up with this. Oh come on. Put up with what? He's just defending himself, and for the record, I agree completely with his standpoint in this whole discussion. It has already been established that EAPI spec is being worked on by enough qualified people - how about everyone drops the subject and lets them work in peace? As for Ciaran bashing Jakub, I can't help but nod (and gasp at some of Jakub's comments) - for quite some time now. Regards, -- Andrej -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On 2/21/07, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: I'm perfectly polite when I'm not replying to the dozenth deliberate attempt to derail something into which I have put a lot of effort... Look, I don't want to waste everyone's time by dismantling in painful detail the foolishness of what you just said, and how it is not an adequate excuse for your behavior. Instead I'll just hit the key points: You can't just launch gratuitous insults at a developer when it appears to be a helpful way to derail someone's totally valid technical suggestions. This doesn't help Paludis, it doesn't help Gentoo, it wastes your time - it helps NO ONE. It's not just offensive to the person you just publicly humiliated, but it's also a slap in the face to all of us who have put a lot of work into making Gentoo a great and fun project to be a part of. Frankly, it would also be a slap in the face if it turns out that no one cares enough about the Gentoo community to remove you, and others that behave like you, if there are any others, from our mailing lists. Otherwise, a few are allowed to ruin the experience of all. Also, talk about derailing Paludis - *your behavior* is what's derailing the future of Paludis and making people uncomfortable with your solo development style. I will not use Paludis, contribute to it, or suggest that others use it simply because I don't like how you find it so easy to shamelessly berate other people. To have a successful open source project, you need to be at least somewhat successful at getting along with people. You at least need to try. You are not trying. Also, Paludis looks like it is, overall, a well-designed re-implementation of Portage, but I hope you don't think it's so wonderful that you think you can act like a total jerk and expect the project will be a long-term success. *No* project is that wonderful. In fact, I would expect that the way you are acting will lead to others working aggressively to try to ensure that Paludis becomes irrelevant by the time it is completed. It's just human nature, and human psychology and human nature typically drive open source projects. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On 2/22/07, Daniel Robbins <[EMAIL PROTECTED]> wrote: On 2/21/07, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > Are you insane? What on earth could Jakub possibly contribute? If you > want a rough indication of Jakub's level of ebuild understanding, take > a look at bug 160328. Is there any process in place to ban people from the gentoo-dev mailing list who are chronically verbally abusive and make no effort at all to be polite? We shouldn't have to put up with this. ++ -- Ioannis Aslanidis 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Clearly you are more concerned about getting Paludis ready. spb has other priorities, fair enough, but this is something that seems fairly important for gentoo as a whole. In process terms, I can't understand why the team working on it isn't a pkgcore dev (eg marienz if you can't communicate with ferringb), a portage dev such as zmedico, yourself from paludis and say antarus from treecleaners. I'd add in someone like jakub or spanky from bug wranglers and Gianelloni for the infrastructure. Having it all from one set of devs (paludis) is like having w3c standards written by one company. While treecleaners really doesn't have anything to do with PMS; I am a portage dev. However I'm not really interested in writing the spec itself; I plan on looking at it when it is closer to completion. I don't claim to have the requisite bash or ebuild magic to author this document (nor do I really care about certain aspects of PMS). I'm more concerned about people changing the tree for paludis compatability; but in most of the cases I've seen the changes requested seemed reasonable to me. I think the whole deal is blown out of proportion, mostly because many people dislike Ciaran, and unfortunately Ciaran dislikes (or distrusts, may be a better word) many other people (myself and Brian Harring included). If the aim is to get everyone to work together to make a big happy spec; I just don't see it happening (the teams really don't get along well when discussing technical issues). The only potential issue is that PMS comes out and the aforementioned 'meddlers' make their statements and it is a situation that is beyond reconcilliation. You've basically written a PMS that may never get approved just because we will never agree on a standard anyway (due to specific differences in how we view a PM working). In essence, delaying all the confrontation to the end. Which is cool with me; tbh ;) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Wed, 21 Feb 2007 21:48:49 -0700 "Daniel Robbins" <[EMAIL PROTECTED]> wrote: | On 2/21/07, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: | > Are you insane? What on earth could Jakub possibly contribute? If | > you want a rough indication of Jakub's level of ebuild | > understanding, take a look at bug 160328. | | Is there any process in place to ban people from the gentoo-dev | mailing list who are chronically verbally abusive and make no effort | at all to be polite? I'm perfectly polite when I'm not replying to the dozenth deliberate attempt to derail something into which I have put a lot of effort... This thread is a perfect illustration of why PMS access is restricted. There are a bunch of people out there who have nothing better to do than try to sabotage the process by posting endless absurd suggestions which can't even be ignored because ignoring them is taken as a sign that their trolling is raising valid issues. Unfortunately, it appears that not having access to the actual material doesn't matter to them -- instead, they just attack the process. -- 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: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On 2/21/07, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: Are you insane? What on earth could Jakub possibly contribute? If you want a rough indication of Jakub's level of ebuild understanding, take a look at bug 160328. Is there any process in place to ban people from the gentoo-dev mailing list who are chronically verbally abusive and make no effort at all to be polite? We shouldn't have to put up with this. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 04:04:37 + Steve Long <[EMAIL PROTECTED]> wrote: | > I'm saying that until there is an independent implementation, the | > specification is worthless and will contain huge numbers of errors. | | Seriously? Without an implementation, your spec of what should happen | will have loads of errors? Yes. It will describe what people think is allowed, rather than what really is. Perfect example -- we'd never have caught the multiple sourcing issue without an independent implementation. | Clearly you are more concerned about getting Paludis ready. spb has | other priorities, fair enough, but this is something that seems | fairly important for gentoo as a whole. Only if you consider replacing Portage to be important for Gentoo as a whole. Which I do, but one also has to have something with which to do the replacing... | In process terms, I can't understand why the team working on it isn't | a pkgcore dev (eg marienz if you can't communicate with ferringb) Because a) they haven't asked, b) they're more interested in replacing the ebuild format and c) every other time they've gotten involved they've been highly unhelpful. | a portage dev such as zmedico We have a Portage dev reviewing it. | and say antarus from treecleaners. What on earth do tree cleaners have to do with it? | I'd add in someone like jakub Are you insane? What on earth could Jakub possibly contribute? If you want a rough indication of Jakub's level of ebuild understanding, take a look at bug 160328. | or spanky from bug wranglers Why? What on earth do bug wranglers have to do with a package manager specification? If Mike wants to contribute he's more than welcome to, but it wouldn't be in a bug wrangling role... | and Gianelloni for the infrastructure. And what on earth do infrastructure have to do with a package manager specification? Somehow I don't think you have the slightest clue what the scope of the document is... -- 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: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Ciaran McCreesh wrote: > | 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. Seriously? Without an implementation, your spec of what should happen will have loads 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. > Clearly you are more concerned about getting Paludis ready. spb has other priorities, fair enough, but this is something that seems fairly important for gentoo as a whole. In process terms, I can't understand why the team working on it isn't a pkgcore dev (eg marienz if you can't communicate with ferringb), a portage dev such as zmedico, yourself from paludis and say antarus from treecleaners. I'd add in someone like jakub or spanky from bug wranglers and Gianelloni for the infrastructure. Having it all from one set of devs (paludis) is like having w3c standards written by one company. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Brian Harring wrote: > Offhand, if the council (majority, no offense meant but not just > one council member who is also a paludis dev) is happy with the state > of things and timelines, then I'll gladly retract the request. > Is this the case; are the majority of the council happy? -- gentoo-dev@gentoo.org mailing list
