2010/1/18 Brian Harring :
> 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
> counterp
On Sun, Jan 17, 2010 at 11:09:07AM +, Ciaran McCreesh wrote:
> 2010/1/17 Christian Faulhammer :
> > Ciaran McCreesh :
> > As much as you love to have the new and shiny VDB2, it is far off.
> > Prototyping and drafting implementations would be great to have some
> > base where we can discuss on
2010/1/17 Christian Faulhammer :
> Ciaran McCreesh :
> As much as you love to have the new and shiny VDB2, it is far off.
> Prototyping and drafting implementations would be great to have some
> base where we can discuss on (in a civil manner). So having this
> timestamp would be a good way to pr
Hi,
Ciaran McCreesh :
> That probably wouldn't be possible. One of the reasons we want to
> ditch VDB is to allow multiple slots of the same cat/pkg-ver to be
> installed in parallel (which is in turn necessary to allow some of the
> more hideous dynamic slot abuses that people are after). VDB doe
On Tue, Oct 27, 2009 at 11:32:30AM -0700, Zac Medico wrote:
> Brian Harring wrote:
> > The proposal is pretty simple; if code modifies the vdb in any
> > fashion, it needs to update the mtime on a file named
> > '.modification_time' in the root of the vdb.
>
> I'd to prefer using the mtime of th
Brian Harring wrote:
> The proposal is pretty simple; if code modifies the vdb in any
> fashion, it needs to update the mtime on a file named
> '.modification_time' in the root of the vdb.
I'd to prefer using the mtime of the /var/db/pkg directory itself,
since existence of a '.modification_time
