From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC
Date: Thu, 26 Nov 2009 16:46:49 +0000 [thread overview]
Message-ID: <20091126164649.780f491c@snowcone> (raw)
In-Reply-To: <20091126163302.GD6082@hrair>
[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]
On Thu, 26 Nov 2009 08:33:03 -0800
Brian Harring <ferringb@gmail.com> wrote:
> > "Provide proof that all existing and future caches that would rely
> > upon this validation mechanism are functions purely and exclusively
> > dependent upon the VDB content, and I shall be happy to make the
> > change."
>
> First I've seen this question actually or at least this particular
> interesting phrasing. That said, "no" comes to mind, since the
> requirement you set is daft.
It's clipboarded from the bug.
> The timestamp updating is for whenever the vdb content (addition of a
> pkg, pkgmoves being applied, removal of a pkg, modification of
> metadata, etc) is changed. That's all that timestamp is for. Vdb
> content.
>
> In light of what the timestamp is, your demand for proof is pretty
> off the mark. If you still consider it to be a valid question,
> please rephrase it and clarify why exactly proof must be provided
> that people reading that timestamp (which is for vdb content only)
> will only be using that timestamp for vdb content.
>
> Your request is akin to demanding proof that a hammer only be used as
> a hammer. It's a fricking hammer- it has one use, one way of being
> used. If someone goes out of their way to be an idiot, they're an
> idiot, not the specs problem.
>
> Seriously, if you're actually worrying about some specific usage
> case, state it- on the face of it, your request for proof right now
> makes zero sense. Kindly provide a scenario or elucidation.
You're asking for a cache validation mechanism that's based not upon
what it logically invalidates, but upon something you assume to be
equivalent. Specifically, you assume that "VDB has changed" and "the
installed packages have changed" are exactly the same thing, and you're
wanting to build a cache based upon that highly questionable
assumption. There are at least two logically different sets of
'changes' that might apply to VDB (metadata changes, and package
version changes), and you're attempting to confuse the two, along with
any others that people come up with later on.
What's wrong with, instead, having cache files for "something has
changed", "the set of installed packages has potentially changed", "the
metadata for installed packages has potentially changed" and "the set of
installable packages has potentially changed"? That way you can write
your cache checks to depend explicitly upon the thing upon which they
depend (along with a global catch-all to make future new validation
mechanisms easier), not upon something you assume is equivalent but
probably isn't.
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2009-11-26 16:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-25 21:50 [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC Denis Dupeyron
2009-11-26 1:34 ` Brian Harring
2009-11-26 1:39 ` Zac Medico
2009-11-26 15:31 ` Ciaran McCreesh
2009-11-26 16:33 ` Brian Harring
2009-11-26 16:46 ` Ciaran McCreesh [this message]
2009-11-27 8:08 ` Brian Harring
2009-11-30 11:30 ` Antoni Grzymala
2009-11-30 11:41 ` Antoni Grzymala
2009-11-30 21:18 ` [gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting) Richard Freeman
2009-11-30 22:28 ` Dawid Węgliński
2009-12-01 1:27 ` Robin H. Johnson
2009-12-03 10:32 ` [gentoo-dev] Individual developer signing Torsten Veller
2009-12-03 12:51 ` Thilo Bangert
2009-12-03 20:35 ` Robin H. Johnson
2009-12-11 16:32 ` [gentoo-dev] " Torsten Veller
2009-12-01 1:08 ` [gentoo-dev] Tree Integrity GLEPS for final review and council approval Robin H. Johnson
2009-11-30 17:57 ` [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC Thomas Sachau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091126164649.780f491c@snowcone \
--to=ciaran.mccreesh@googlemail.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox