Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Brian Harring]

On Sun, Dec 18, 2005 at 12:14:30AM +0000, Ciaran McCreesh wrote:
> On Sat, 17 Dec 2005 15:33:18 -0800 Brian Harring <ferringb@g.o> wrote:
> | On Wed, Dec 14, 2005 at 09:54:06PM +0000, Ciaran McCreesh wrote:
> | > Well, if Portage ever gets multiple repository support, then news
> | > clients can be updated to handle it. The GLEP says that already.
> | Care to clarify how that transition is going to occur?
> |
> | Your proposal, if you know a roadblock is coming down the line I
> | expect it to be documented in the glep (with potential suggestions
> | how to minimize the horkage).
>
> It'll probably just be a case of updating news clients to query Portage
> somehow for a list of repository IDs and using appropriately named news
> files.

Transitioning from single news.unread to N is going to break clients 
that expect a single.

As I said, you're going to break stuff- and you're building it into 
your glep out of (aparent) stubborness.

What do you want, another glep amending yours with that one little 
detail?  Or someone just gets off their ass and tweaks your glep, gets 
another glep #, and stops the pointless arguing with you and pushes 
a competing glep?

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.


> Hard to say for sure without details of how exactly multiple
> repository support will work though -- for example, if you're going to
> allow fancy characters in repository names then some kind of name
> mangling standard will need to be defined.

Standard ascii, same rules required for glep31.


> | 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.


> | Thing that's daft out of all of this time wasting is that what's
> | being asked of you is a couple of portageq calls so that we're not
> | screwed over by a feature.  Something along the lines of...
> |
> | portageq get_repo_id path # helper method of getting repo_id for a
> | path (dar) portageq match root atom [repo-id] # method of limiting
> | matching of vdb to a specific source repo
> | portageq newsdir repo_id  # get the absolute news path for said id.
>
> You're asking me to guess how Portage multiple repository support will
> work, and then ask for a bunch of changes to Portage to support
> appropriate dummy functions.

I'll remind you that portage devs have stated this is required for 
your damn glep.  Iow, collaboration here is required- work out the api 
that you need that fits in with what we need, instead of wasting our 
time arguing over whether you should do it or not.


> Unless you're prepared to commit
> yourselves to saying "multiple repository support will work like
> $blah", I'm not going to even think about asking you to restrict
> yourselves to a particular implementation...

There's no asking here; you're pushing a glep, we've stated in it's 
current form constrains *our* efforts long term.

Word games suck, instead of playing them you *should* be trying to 
address the concerns- iow, what do you *explicitly* need from portage, 


> 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".


> | If it's too slow, I'd suggest since it's your proposal, looking for a
> | method to batch up the calls (modularization of portageq would be
> | required, which is available in the dead ebd branch already).  Tricks
> | of that sort are easily implemented, and don't require specs and
> | gleps (just requires someone to do a minor bit of work).
>
> That's not likely to be a major performance hit... We're not expecting
> the user to have more than a few repositories, are we?

Stated it to cut off any angle of "waah, can't go that route, 
portageq calls are to slow".

Something your glep doesn't clarify and I want nailed down in stone 
(since at your request we are being explicit here), is how the 
'package manager' is going to track news items that are marked as 
unread already, further the news.skip file.

Basically... you're the glep author/champion, implementing the portage 
modifications are your responsibility (we may help, but it's your job 
to do it).  Since this proposal *is* complicating portage, hand waving 
of the sort "implementation is not specified by this GLEP" I want 
nailed down.

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).
~harring