relying on vdb only

Hi,

reading comments on bug 209538, I've seen this dangerous
thing from Zac:

"Once these issues are solved it will be nice if we can
rely exclusively 
on the dependencies from /var/db/pkg."

Well, the idea that devs will have to revbump packages just
for RDEPEND 
version restrictions so that portage picks it freaks me 

Then there's: "I do have a tool that copies metadata
from ebuilds but 
I'd prefer to avoid doing anything like that if
possible."

So maybe it's time to discuss what's possible? 
If that discussion already happens/happened elsewhere, then
sorry for 
noise and please point me there 

Thanks,
Caster
-- 
gentoo-portage-devlists.gentoo.org mailing list

On Mon, Feb 11, 2008 at 09:48:01AM +0100, Vlastimil Babka
wrote:
> Hi,
> 
> reading comments on bug 209538, I've seen this
dangerous thing from Zac:
> 
> "Once these issues are solved it will be nice if
we can rely exclusively 
> on the dependencies from /var/db/pkg."
> 
> Well, the idea that devs will have to revbump packages
just for RDEPEND 
> version restrictions so that portage picks it freaks me

> 
> Then there's: "I do have a tool that copies
metadata from ebuilds but 
> I'd prefer to avoid doing anything like that if
possible."
> 
> So maybe it's time to discuss what's possible? 
> If that discussion already happens/happened elsewhere,
then sorry for 
> noise and please point me there 

Relying on the vdb is far saner then relying on the tree; so
no, it's 
not particularly dangerous, the inverse (relying on the tree
to have 
the same deps for vdb) is far worse imo.

Solution to this is to reuse the existing update
infrastructure, and 
add a new command into it that resets the depends/rdepends-
haven't 
looked to see if older portage versions would behave well if
they 
encounter an unknown command in profiles/updates/* however.

~brian

On Monday 11 February 2008 12:50:39 Brian Harring wrote:
> On Mon, Feb 11, 2008 at 09:48:01AM +0100, Vlastimil
Babka wrote:

> > Well, the idea that devs will have to revbump
packages just for RDEPEND
> > version restrictions so that portage picks it
freaks me 
> >
> > Then there's: "I do have a tool that copies
metadata from ebuilds but
> > I'd prefer to avoid doing anything like that if
possible."
> >
> > So maybe it's time to discuss what's possible?

> > If that discussion already happens/happened
elsewhere, then sorry for
> > noise and please point me there 
>
> Relying on the vdb is far saner then relying on the
tree; so no, it's
> not particularly dangerous, the inverse (relying on the
tree to have
> the same deps for vdb) is far worse imo.
>
> Solution to this is to reuse the existing update
infrastructure, and
> add a new command into it that resets the
depends/rdepends- haven't
> looked to see if older portage versions would behave
well if they
> encounter an unknown command in profiles/updates/*
however.
>
> ~brian

This should really be [possible|done] without introducing
yet another ugly and 
very difficult to maintain update/* hack?
-- 
gentoo-portage-devlists.gentoo.org mailing list

On Mon, Feb 11, 2008 at 12:58:51PM +0100, Selckin wrote:
> On Monday 11 February 2008 12:50:39 Brian Harring
wrote:
> > On Mon, Feb 11, 2008 at 09:48:01AM +0100,
Vlastimil Babka wrote:
> 
> > > Well, the idea that devs will have to revbump
packages just for RDEPEND
> > > version restrictions so that portage picks it
freaks me 
> >
> > Relying on the vdb is far saner then relying on
the tree; so no, it's
> > not particularly dangerous, the inverse (relying
on the tree to have
> > the same deps for vdb) is far worse imo.
> >
> > Solution to this is to reuse the existing update
infrastructure, and
> > add a new command into it that resets the
depends/rdepends- haven't
> > looked to see if older portage versions would
behave well if they
> > encounter an unknown command in profiles/updates/*
however.
>
> This should really be [possible|done] without
introducing yet another ugly and 
> very difficult to maintain update/* hack?

Err... hack?  Justify that statement please.

Few things you might as well address also-
1) update/* runs once per sync; alternatives (building a
mapping, or 
forcing 2x metadata lookup via hitting up the tree for new
metadata) 
can't really compete from a amoritized cost standpoint
2) it's simple to maintain; exact atom (rev included),
metadata key, 
metadata value.  Can't realistically rewrite eapi-1 IUSE via
it 
(default iuse can change the pkgs USE configuration), same
for other 
build values (CHOST), but it's powerful, and simple.
3) basic infrastructure is already there, so why not reuse
it?

~brian