Re: [gentoo-pms] [PATCH] Make it clear that PMs are allowed to handle 'invalid' names.

[Brian Harring]

On Sun, Sep 23, 2012 at 12:41:06AM +0200, Micha?? G??rny wrote:
> ---
>  names.tex | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/names.tex b/names.tex
> index decc8f4..5a3866f 100644
> --- a/names.tex
> +++ b/names.tex
> @@ -2,8 +2,10 @@
>
>  \section{Restrictions upon Names}
>
> -No name may be empty. Package managers must not impose fixed upper boundaries upon the length of any
> -name. A package manager should indicate or reject any name that is invalid according to these rules.
> +No name may be empty. Package managers must not impose fixed upper
> +boundaries upon the length of any name. A package manager should
> +indicate or reject any name that is invalid according to these rules.
> +Package managers are allowed to accept names not following those rules.

"Here's some rules.  You must abide by them.  Or you can ignore them."

This patch really doesn't deserve a response on that alone.


Honestly, it's a stupid minor wart of PMS names that's a pain in the 
ass to remove, and was added at the time (going from memory, but this 
should be accurate) because portage internally used a combined cp/cpv 
parser, and didn't pass in context as to whether or not a version was 
needed- and the code consuming that results didn't enforce 
version/non-version matching operator.  Meaning an atom of 
'dev-util/diffball-1' portage would be view as 'dev-util/diffball'.


Annoying?  Fuck Yes.  Worth removing?  Sure, after scoping the 
breakage, and figuring out the implications for code that doesn't 
support the new rules in light of the fact the vdb's package names 
rules are *unversioned*.  That's the real problem here, not setting 
some "well we'll just block it from being usable in gentoo-x86; 
problem solved!".

Offhand, and frankly I'm kind of pissed I had to even do this legwork 
because your noisy fucking ass couldn't be bothered to do the 
the necessary legwork looking at sources (god forbid rather 
than chattering like a poop-flinging monkey, someone fire up a term 
and go grep'ing and reading sources); right now, changing the rule 
that way means that a package name of 'diffball-1' would break on 
portage, pkgcore, and paludis.  In other words, as has been said, 
all current versions, and likely versions from years ago, *will* 
go boom if they encounter this.

In portages case, the exact consequence are hard to state- their 
design isn't exactly centralized, but whacky/fantactistcally/daffy 
results should be expected.  Minimally it spots the borkedness, but to 
identify exactly what it'll do in each case requires checking each 
case; as said, they don't have a centralizd handling.

Minimally, pkgcore and paludis, current versions see this anywhere, 
they *will* throw an exception because its broken data- to make it 
into the vdb is either corruption of the disk, or corruption of the 
VDB by a broken PM implementation.  Both things have to be flagged, 
even though it sucks, and that's what we do.

For portage, go figure out the results; I already know it flags 
'diffball-1' as a bad package name, the full way that causes 
explosions, don't know, but I've already burnt 20 minutes doing 
legwork you should've done, so now you need to go do the legwork for 
your fucking proposal.

~harring