Re: [gentoo-dev] glep 42 (news) round six

[Brian Harring]

On Sun, Dec 18, 2005 at 04:52:23PM +0000, Ciaran McCreesh wrote:
> On Sat, 17 Dec 2005 23:27:32 -0800 Brian Harring <ferringb@g.o>
> wrote:
> | To head off the "don't make features that are easily screwed up",
> | this isn't one of them- this is expecting code to behave correctly
> | from the path standpoint.
>
> Hrm, so will we be allowing spaces in package and category names too?

No, due to atoms in *depend being seperated by whitespace.  Wouldn't 
work without introducing escaping into it- beyond that the cat/pkg 
standard is in place already.

Your repo_id however, is not, thus it's mallable.

It's irrevelant either way- as I stated, your code *needs to be* space 
safe.  Existing repo label'ing code in saviour _already_ allows spaces 
(it's just a fricking name), dissallowing spaces due to a concern that 
someone might screw up is daft.

So... don't point at other things that are already set in stone and 
disallow spaces for their own reasons; state why it must be disallowed 
here, or merely state "I hate spaces".

Like I said a couple of emails back, block spaces in repo_id if you 
like, either way the code involved has to be space safe for paths, so 
it's an arbitrary restriction...

Dunno.  Either way, path handling *must* be space safe anyways- if you 
restrict repo_id to lack spaces, your choice, still going to allow external 
aliasing of the repo_id to have spaces.


> | > I don't want to introduce any signing requirements that we don't
> | > have already. When signing for everything else becomes mandatory,
> | > signing for news would be too. If I make this a 'must', someone
> | > will ask me to specify how we're handling the Gentoo keyring...
> |
> | Pawn the keyring off on others.  The issues isn't an established
> | trust ring, it's required signing- yes, a trust ring makes things a
> | helluva lot easier on the user front, but it's useless without a
> | required signing policy.
> |
> | We've already had this conversation also btw, in the
> | beginning of glep42 iirc.  Obviously I don't agree
> | with your reasoning "I'll do it when it's required I do it".  It's
> | useful now, it becomes massively more useful when a trust ring is
> | available.
>
> Ok, how about I change it to "must", and add a note under Backwards
> Compatibility along the lines of:
>
> At the time of writing, there is no standardised mechanism for handling
> GPG signatures in Gentoo. Until such a mechanism exists, GPG signing
> cannot be considered mandatory.

And provisions for going back and signing everything that was _not_ 
signed while you delaying waiting for a keyring?

That's why I'm pushing it.  Mandate it as required now, keyring down 
the line just makes it more useful.  Make it 'suggested' (which this 
is, you've changed nothing but words), you've left a mess that needs 
to be addressed when keyring comes about.

Same scenario as before, think forward- force it from the get go, less 
crap to deal with down the line.  Mandate it, no mess- just the 
pre-existing problem of getting a keyring collected.

Delay it, keyring + going back and trying to get folk to re-sign their 
releases.  That and any unsigned material released during that period 
cannot be verified, because we're waiting for a keyring.

See the gains?  Might be unpalatable, but it is the path of least work 
long term.


> Ok, how's this?
>
> ``Revision:``
>     Initially 1. Should be incremented every time a change is made to
> the news item. Changes that require a re-read of the news item (for
> example, most changes that are not spelling or formatting related)
> should instead use a new news item. Mandatory.

Works, thank you.


> | > | This isn't incredibly useful if ranged versions are ever
> | > | introduced. Ammending the glep for that seems stupid, looser
> | > | language might be wise.
> | >
> | > What's the syntax for ranged versions? And how do they differ from
> | > SLOT versions?
> |
> | >=kde-base/kde-libs-3.0 <=kde-base/kde-libs-4.0
> |
> | It's not syntax as much as a boolean and of atoms.
>
> Hrm, ok. Wouldn't this resolve as true if you have kde-libs-2.0 and
> kde-libs-5.0 installed (assuming SLOTted kde-libs)?

Note I said boolean and.  Resolution of that string *should* result 
in 3-4 via portage processing of it; doesn't handle it perfectly, but 
the reason I brought it up is that via limiting it to a single atom, 
you block (if/when) ranged versions.


> | Any signed item would need to be verified also, although fortunately
> | this chunk can be done in parallel to regen run.
>
> Hrm, is signing verification done for tree items?

*If* a component was fully signed, verification prior to dissemination 
should occur.  Reliant on a keyring to automate it however, plus some 
voodoo to make as much as possible go in parallel (so as not to 
overrun the window).


> | > | You haven't stated how the 'package manager' will trigger the
> | > | user's reader of choice for these targets.  Should also extend
> | > | this to allow a way to disable any news notices, lest someone's
> | > | cronjob get hung displaying news (feature or not, it's needed).
> | >
> | > The same way the package manager handles updating config files: it
> | > won't. It'll just tell the user that some news items need reading.
> |
> | And you'll personally handle all of the bug spam from feature
> | requests that --ask trigger $news_reader?
> |
> | It's a logical extension, thus people will ask for it.
>
> What does emerge --ask do currently for config files?

see email responding to marius about why etc-update and friends aren't 
the best example...

Personally, I'm not much for triggering the news reader, but I'd 
expect folks will want a way to trigger the user's preferred reader.  
That's the crux of this question- you've bound this cruft into 
eselect, would assume there is a way to trigger the default reader 
(guessing at least).

If there is some way to trigger whatever the default news reader is, 
then the --ask cruft can be ignored; just asking about something as 
simple as a symlink, so if the request comes up (it will, imo), it's 
doable rather then trying to go and modify the existing clients to 
support it.

</ramble>

~harring