FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 11-25-2009, 08:50 PM
Denis Dupeyron
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want
us to discuss things please let us know in reply to this email. What
is already known is we'll talk about mtime preservation and prefix.
You can find threads about those at:
http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml
http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml

Denis.
 
Old 11-26-2009, 12:34 AM
Brian Harring
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

On Wed, Nov 25, 2009 at 02:50:22PM -0700, Denis Dupeyron wrote:
> The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want
> us to discuss things please let us know in reply to this email. What
> is already known is we'll talk about mtime preservation and prefix.
> You can find threads about those at:
> http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml
> http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml

I'd like
http://archives.gentoo.org/gentoo-dev/msg_6b3e00049a1bf35fbf7a5e66d1449553.xml
to be discussed, specifically zacs form of forced mtime updating of
/var/db/pkg on vdb modifications

Reiterating the reasoning, it'll be used for enabling the managers to
manage caches, specifically invalidating said caches if an alternative
manager modifies the vdb.

End result, if we can build better caches for vdb, vdb access can be
heavily sped up.

At this point, pkgcore/portage both have it implemented. Not sure if
portage has released it yet, but >=pkgcore-0.5.2 is in the tree w/
said updating support.

~harring
 
Old 11-26-2009, 12:39 AM
Zac Medico
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

Brian Harring wrote:
> At this point, pkgcore/portage both have it implemented. Not sure if
> portage has released it yet, but >=pkgcore-0.5.2 is in the tree w/
> said updating support.

It's in >=portage-2.1.7.2 (and 2.1.7.x should be going stable in a
month or so).
--
Thanks,
Zac
 
Old 11-26-2009, 02:31 PM
Ciaran McCreesh
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

On Wed, 25 Nov 2009 17:34:38 -0800
Brian Harring <ferringb@gmail.com> wrote:
> I'd like
> http://archives.gentoo.org/gentoo-dev/msg_6b3e00049a1bf35fbf7a5e66d1449553.xml
> to be discussed, specifically zacs form of forced mtime updating of
> /var/db/pkg on vdb modifications

I've still not had an answer to:

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

Without that proof, all introducing that change would do is provide
another unreliable mechanism, so it's of no use at all.

--
Ciaran McCreesh
 
Old 11-26-2009, 03:33 PM
Brian Harring
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

On Thu, Nov 26, 2009 at 03:31:17PM +0000, Ciaran McCreesh wrote:
> On Wed, 25 Nov 2009 17:34:38 -0800
> Brian Harring <ferringb@gmail.com> wrote:
> > I'd like
> > http://archives.gentoo.org/gentoo-dev/msg_6b3e00049a1bf35fbf7a5e66d1449553.xml
> > to be discussed, specifically zacs form of forced mtime updating of
> > /var/db/pkg on vdb modifications
>
> I've still not had an answer to:
>
> "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.

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.

~harring
 
Old 11-26-2009, 03:46 PM
Ciaran McCreesh
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

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
 
Old 11-27-2009, 07:08 AM
Brian Harring
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

On Thu, Nov 26, 2009 at 04:46:49PM +0000, Ciaran McCreesh wrote:
> 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."
> > 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.

Ah... there we go, you're again asking for specific timestamps such
that specific caches can be invalidated. Same as I said in the bug,
you want it, propose it. As you stated above, *still* a global
timestamp of some sort is needed.

Seriously- if you want some specific cache timestamp, go nuts. The
global timestamp is still needed and that's the only one I give a damn
about at this juncture- I'm not as much interested in layering in new
hacky caches on the vdb to try and make it performant as I'm
interested in building flat out, a new vdb that is designed from the
ground up for efficiency/performance.

When the old vdb format has the timestamp requirements, I can use that
to keep the two in sync (maintaining compatibility while being free
to start developing a better vdb, or alternate implementations- say
remote). Beyond that, for people less ambitious it serves as a
timestamp they can use for updating their own caches- not the most
fine grained admittedly, but it's also a rare scenario.

Either way, you want specific cache timestamps, it's an addition to
this proposal- for example I'm specifically disinterested in adding a
pkg names cache because the gain from it isn't particularly high for
the scenarios I'm looking at (provides/use/iuse/depends/rdepends per
node being higher cost in my profilings). Admittedly it speeds up
simple lookups in the vdb of "what version do I have installed?", but
most folk do a pmerge/emerge -Dup for that (meaning full metadata
access still).

~harring
 
Old 11-30-2009, 10:30 AM
Antoni Grzymala
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

Denis Dupeyron dixit (2009-11-25, 14:50):

> The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want
> us to discuss things please let us know in reply to this email. What
> is already known is we'll talk about mtime preservation and prefix.
> You can find threads about those at:
> http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml
> http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml

Hi!

How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort
a year ago to summarize the then-current state of things regarding tree
and package signing, however the matter seems to have lain idle and
untouched for more than a year since.

I reckon that missing GPG infrastructure is one of the greatest problems
of the Gentoo distribution esp. regarding serious corporate and academic
deployments.

I can devote some time to helping with the matter.

Regards,

Antoni GrzymaƂa

--
[a]
 
Old 11-30-2009, 10:41 AM
Antoni Grzymala
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

Antoni Grzymala dixit (2009-11-30, 12:30):

> Denis Dupeyron dixit (2009-11-25, 14:50):
>
> > The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want
> > us to discuss things please let us know in reply to this email. What
> > is already known is we'll talk about mtime preservation and prefix.
> > You can find threads about those at:
> > http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml
> > http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml
>
> Hi!
>
> How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort

[...]

Forgot the URL, of course:

[1] http://www.gentoo.org/proj/en/glep/glep-0057.html

--
[a]
 
Old 11-30-2009, 04:57 PM
Thomas Sachau
 
Default Next council meeting on 7 Dec 2009 at 1900UTC

Denis Dupeyron schrieb:
> The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want
> us to discuss things please let us know in reply to this email. What
> is already known is we'll talk about mtime preservation and prefix.
> You can find threads about those at:
> http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml
> http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml
>
> Denis.
>
>

Hm, i requested the discussion of real multilib support for portage 2 months ago, i requested it for
the following council meeting, i requested it for the last council meeting and i requested it for
the next council meeting. I hope, it will finally get a place on 7 Dec 2009.

I have a git branch with a modified 2.2_rc* version of portage with included multilib support. I
already wrote about basic implementation 2 months ago in the conversation on this list with vapier.

Since zmedico wants a council-ok before accepting any patches for multilib-support in portage, i
request this. My main idea behind this request is, that more people will have a look and there are
potentially more people involved in improving it. In addition it allows more people to easily get
required 32bit libs the way they want them (specific version, specified USE flags, self-compiled, so
up-to-date unlike the emul-linux-x86-* packages).

Since the code may change in the future, my idea is to restrict it currently only to 2.2_rc*
versions and in addition a required feature (e.g. FEATURES="multilib"). Once everyone is ok with the
code and the way it works, it could be proposed as an PMS-update. If other PM-mantainers are
interested in improving it before, they are of course free to also help improving the code and the
way it works.


--
Thomas Sachau

Gentoo Linux Developer
 

Thread Tools




All times are GMT. The time now is 12:37 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org