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 +0000, Ciaran McCreesh wrote:
> > > > On Thu, 22 Feb 2007 04:04:37 +0000 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.
<looking up>
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
>
> <snip>
>
> > 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
--
[email protected] mailing list
