Re: [gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)

[Ciaran McCreesh]

2010/1/18 Brian Harring <ferringb@×××××.com>:
> Propose something, or shut up frankly.

I propose we don't do anything until someone comes up with a decent
cache proposal.

> If all you're going to contribute is "it's half baked" claims, you're
> wasting folks time.  You've had a couple of months of time to
> counterpropose something- back it up with a proposal or be silent
> please.

Doing nothing is better than doing something useless.

> As is, quite a few folk see how experimental vdb2/vdb1 synchronization
> can be done w/ this timestamp- your claims thus far that it won't work
> seem to boil down to "but not everyone will update the timestamp".

Er, no. It comes down to VDB2 implementing things that VDB1 doesn't
support, such as having multiple installed slots of the same
cat/pkg-ver, thus making it impossible to have both VDB1 and VDB2 at
the same time.

I have never argued against this proposal because "not everyone will
update the timestamp". That's an argument you've made up and
attributed to me.

> Which gets right back to why I'm elevating this to the council to
> *force* PMS to include this, thus force the holdout (paludis) to
> update the timestamp thus invalidating your cyclical claim.

PMS doesn't mention VDB at all. You're barking up the wrong tree. If
you want me to include it in Paludis, all you have to do is come up
with a proposal that does everything we need, rather than a proposal
that can't legally be used for anything at all.

> What I won't do is sit around and listen to you whinge about the sky
> falling or that I/others are being idiots via not going
> the route *you* want and standardizing caches across all the managers-
> as I said, you want that functionality *you* propose it.

I propose that rather than implementing a half-baked cache that isn't
usable for anything, we do nothing until someone does come up with a
full, unified cache proposal, where the validity of caches after
operations is well defined.

> It's not how things should be done, but it's about the only way to get
> something done when you dig in and go cyclical.

Cyclical on what? Explain where there is a cycle anywhere. You keep
claiming I "go cyclical", but never point out any actual cycles. It's
what you fall back on when you don't have an argument.

> Wish it weren't that way, but I've more interest in progress then playing games w/
> folk looking to be poisonous.

And again, the whole "poisonous" thing. It's the last resort of those
who are themselves the poison. How is wanting to do nothing until
something can be done properly, rather than doing something that
doesn't solve anything, poisonous?

> Seriously, if you can't even be bothered to spell out your claims in
> full or layout a counter proposal, instead spending your time
> screaming "nyah nyah it won't work!" as you did for prefix, I'm not
> having it.

Uh, I already did, several times, and you ignored me, snipped them out
and said I was "going cyclical".

I'll also point out that I raised a long list of things that were
wrong with Prefix way back when it all started, and over the past few
months everyone has finally realised that that list was full of
legitimate concerns that are just now being addressed. Is it going to
take you five years to see how I'm right here too? And how much more
damage are you going to do to Gentoo before you admit that, as with
Prefix, I've thought this through properly and you're just rushing
along with the first thing that popped into your head?

So, for you to ignore yet again:

* The proposal does not define exactly what the validity of a cache
is. You are sort of implicitly assuming that the validity of a cache
is a function exclusively of "the VDB not being modified", for some
undefined value of "not being modified", but nowhere are you stating
concretely what the rules are.

* You are addressing *only* VDB validity, rather than doing validity
of all repositories at the same time.

* There is no granularity to the proposal. There is simply an
ill-defined "modified" rule, with no way for a package manager to know
what was modified or by whom.

* You aren't doing anything to fix the zillions of different caches
that package managers have to use.

> There are better uses of folks time frankly, and users deserve
> functionality over daft pissing matches.

Then give them a functional, shared cache, not a cache that can't
legally be used for anything.

-- 
Ciaran McCreesh