On Sun, Dec 18, 2005 at 01:07:27AM +0000, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 16:51:05 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | Transitioning from single news.unread to N is going to break clients > | that expect a single. > > Yup. > > | As I said, you're going to break stuff- and you're building it into > | your glep out of (aparent) stubborness. > > No no. I'm just not adding something ill defined and arbitrary to the > GLEP to avoid introducing minor possible breakage when some ill defined > and arbitrary change is made to Portage.
Well, since we're toeing the line, I'll just state your glep is ill defined and arbitrary, it is inflexible and incomplete due to the fact it doesn't take into consideration the existing solutions (namely overlays). Back off the technical double speak insults unless you want others people to get nastier then they are already. > | What do you want, another glep amending yours with that one little > | detail? > > Probably won't be necessary... If you're unwilling to make your 'flexible' proposal actually flexible for anything but your stuff (eselect), either the glep is going to be fought tooth and nail or a competing glep is going to come out of this. Bluntly, stop being a tool, users want this feature, stop using it as fodder to fight. > | The news glep crosses several groups, collaboration here is required, > | meaning *listen* to the folk you're trying to command. Otherwise the > | glep *will* go nowhere no matter how much noise you make. > > And I'm asking you to provide me with a specification of how multiple > repositories will work. Without that, there's no way the GLEP can be > made to handle multiple repositories. We have overlays already. That *is* multiple repositories. Stop trying to dodge the request by making us waste our time and produce a stand alone repository glep- overlays exist *now*, thus you *do* need to address them *now* else your glep is incomplete. > | > | If you're going to create and dump a mess on us, I expect it to > | > | be in the proposal- especially since your proposal is > | > | intrinsically portage bound. > | > > | > There's very little that's Portage bound. As originally requested, > | > I've tried to keep as much as is reasonably possible *out* of > | > Portage... > | > | It's distributed via the portage tree, it's updated by portage, the > | check for new news items is *via* portage, and check for news items > | prior to merging is done by portage. > | > | If that truly was your intention, you failed in it.. It's bound to > | portage, despite the rhetoric. > > No no. A Portage bound solution would stick all the code and clients in > Portage proper, rather than using Portage merely for hooks as far as is > reasonably possible. Word games... You're dodging my point. > | Word games suck, instead of playing them you *should* be trying to > | address the concerns- iow, what do you *explicitly* need from > | portage, > > What explicitly I need, *if* the GLEP is to specify multiple repository > support from the outset, is a specification of how Portage will handle > multiple repositories conceptually and a description of the interface > that will be provided by Portage. Overlays. The only thing you need is a repo id, the only thing we need is to know what you'll be accessing, what we need to future proof from an api standpoint. > | > Especially since you've said "we're not doing it the way you think > | > it should work"... > | > | Where have I stated that? My statements thus far about multi repo > | were in reference to a glep that missed the target. > | > | Provide quotes please, or get back to nailing down exactly what you > | need portageq wise so we can state "do it this way, and we'll shut > | up". > > I'm thinking mainly about "Portage externally will use user defined" in > relation to repository identification. Any specification on multiple > repositories that comes from me will have said identifiers being > repository designed, simply because I can't see a sane way of handling > it otherwise. We've had this discussion once already, but I'll keep hammering the point till you follow it- external repo label is just that, what the user would specify on commandline. emerge --repo blah --rsync (fex). Internal ids are a seperate beast, and a simple solution *now* is that any repo that provides new must bundle an ID. Do that, and portage can made to use it for your news crap. Aliasing (user naming) is something *we* would add as a feature down the line. Why am I stating it as such? Because again, overlays exist now, and your glep is willfully leaving them out in the cold. > | You want us to nail everything down for our request, I'd like you to > | do the same (especially since we're stuck maintaining whatever you > | propose/create). > > I can't nail down details on multiple repository support until I'm told > what Portage will do. Give me a specification for what Portage will do > and I'll quite happily make the GLEP work with it. Overlays have existed for at least 2 years. Theres your spec. Time to amend your glep so it actually encompasses them, especially considering your glep is a modification of the tree format. ~harring
pgpca836qhBga.pgp
Description: PGP signature
