Re: [gentoo-portage-dev] virtuals and dependencies dispaly

[Brian]

On Wed, 2006-25-10 at 01:48 +0000, Jason Stubbs wrote:

> > virtuals = portage.db[portage.root]["virtuals"]  from
> > gentoolkit.__init__.py
>
> I'm not sure exactly what this returns, but it's probably equivalent to
> portage.settings.virtuals.

I got the same result from both, but this one is easier. There are
probably a few more portage calls that could be updated as well.

>
> > I've found virtuals in the tree that are not in portages virtuals and
> > vice-versa.
> > Is there an order to their use by portage?
>
> atom = "virtual/portage"
> non_virtual_atom = portage.dep_virtual([atom], portage.settings)[0]
>
> if atom == non_virtual_atom:
> 	print atom,"is a 'new style' virtual (aka regular package)"
> else:
> 	print atom,"is an 'old style' virtual that resolves to',
> 	print non_virtual_atom
>

I used this almost without any change.  I also am only calling this if
it did not resolve already from the best_ebuild or latest_installed
checks.

def get_virtual_dep(atom):
    """returns a resolved virtual dependency.
    contributed by Jason Stubbs, with a little adaptation"""
    # Thanks Jason
    non_virtual_atom = portage.dep_virtual([atom], portage.settings)[0]
    if atom == non_virtual_atom:
        # atom,"is a 'new style' virtual (aka regular package)"
        return atom
    else:
        # atom,"is an 'old style' virtual that resolves to:
non_virtual_atom
        return non_virtual_atom


> > Can the ones in the tree be
> > treated as a category/package for listings, etc..  The ones in the tree
> > do seem to be returned by:
> >
> > portage.db['/']['porttree'].getallnodes()[:] # copy
> >
> > The main reason I am looking at this is for indicating the dependency
> > installed/needed for the virtual.  If an installed one is found I use
> > it's package name. If not  where should I get it?  From the virtuals in
> > portage or the tree? both? - then which order?
>
> The ones in the tree are just regular packages - but may also exist in the
> PROVIDE attribute of associated ebuilds. As for ordering, packages with
> PROVIDE override identically named packages in the tree. If you use something
> similar to the above, it should all be taken care of though.

I think these are resolved when I am checking for the best_ebuild and
latest_installed checking.  Before I added your contribution, many were
resolving already from those checks.

>
> --
> Jason Stubbs

Thank you very much...


Now to add a popup dialog to display a dependency's info in another
PackageNotebook class instance (summary, dependency, changelog,...
notebook).  That is going to make following the dependency trail a lot
easier for those that want to follow it.
-- 
Brian <dol-sen@×××××.net>

-- 
gentoo-portage-dev@g.o mailing list