Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-guis
Navigation:
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-guis@g.o, Kuroo Kuroo <kuroo.info@...>
From: René 'Necoro' Neumann <lists@...>
Subject: Re: One backend for all portage GUIs
Date: Wed, 10 Oct 2007 19:47:22 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

René 'Necoro' Neumann schrieb:
> Brian schrieb:
>> On Tue, 2007-09-10 at 23:54 +0200, René 'Necoro' Neumann wrote:
> 
>>> This is the thing I'm waiting for atm ... the functions to implement (ie
>>> the API)... I think, that it should be done in a functional way is
>>> general consensus, isn't it?
>>>
>> Ok, I've put together a small list of portage calls mostly unigue, but
>> many have variations of the basic call (not listed)repeated for
>> different info returned. A few lines of code I left in to make it more
>> clear, but should give an overall list of the portage function calls
>> used so far.
> 
> 
>> I will put together a list of functions that I created in portagelib to
>> add functionality directly related to portage.  Some of them are copies
>> of code chunks from lifted from gentoolkit.
> 
>>> Regards,
>>> - - Necoro
> Thanks =)
> 
> I've put it into the Wiki [1] too. :)
> 
> I'll try again today to create some API documentation and will merge
> your requirements.

Ok - I've added the current API to the wiki [1]. I did not manage to
include all of the needs of porthole, as I don't know what some of the
calls do, and whether they are really needed ;).
Please see the attached file for the comments.

@dol-sen: Would be great if you could scan through the list and see,
which ones are really needed. Because portage calls inside functions
that are then moved into catapult don't need to have an equivalent in
the API (at least in most cases). - And for the vast majority I was just
clueless ^^. (and too lazy to lookup portage code).

There are certain issues with the current API:

1.) Add some more stuff needed by other frontends.
2.) Perhaps merge the Package and the System object as they both just
provide functions.
3.) Merge package.is_in_overlay() and package.get_overlay_path()
4.) Get rid of the different get_*_settings functions and add special
ones: get_homepage, get_depend(which), get_arch, ...
5.) Currently there are two functions returning use flags which were set
at installation time of a package:
	- get_use_flags(): Returning ALL set useflags
	- get_installed_use_flags(): Return only the set useflags which are
also in IUSE.
This should perhaps be merged into one function with an attribute
"only_iuse" or similar.

Some comments are appreciated ;)

- - Necoro

[1] http://catapult.origo.ethz.ch/wiki/API
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDRAq4UOg/zhYFuARAmyxAJ4jqUKg8pAIi6AGv/QYcGZ4XOagkACeOFJK
9XOv2sBduIknjtsKv8CbYqM=
=1FVU
-----END PGP SIGNATURE-----
# already implemented
portage.settings["ARCH"] # system.get_global_settings("ARCH")
portage.catpkgsplit # system.split_cpv()
return portage.best(versions) # system.find_best()
portage.getmaskingreason(ebuild) # package.get_masking_reason()
if portage.portdb.cpv_exists(ebuild): # package.is_in_system()
if vartree.dbapi.cpv_exists(ebuild): # package.is_installed()
dir,ovl = portage.portdb.findname2(cpv) # package.is_in_overlay(); package.get_overlay_path()
return portage.db['/']['vartree'].getebuildpath(fullname) # package.get_ebuild_path()
portdb.findname(mycpv) # package.get_ebuild_path()

# needs to be implemented
return portage.settings.virtuals # ??

# unknown; guess is that it needs to be implemented
portage.pkgsplit(ebuild) # what does this do?
portage.archlist[:] # ??
portage.config(clone=portage.settings).environ()[var] # ??
return portage.db['/']['vartree'].dep_match(str(package_name)) # ??
return portage.portdb.xmatch(*args, **kwargs)[:] # ??
fetchlist = portdb.getfetchlist(mycpv, mysettings=settings, all=True)[1] # ???
mysum[0] = mf.getDistfilesSize(fetchlist) # ???
portage.db['/']['porttree'].dbapi.finddigest(ebuild) # ???
non_virtual_atom = portage.dep_virtual([atom], portage.settings)[0] # ??

# unknown
mf = portage_manifest.Manifest(pkgdir, settings["DISTDIR"]) # ????
return portage.db['/']['porttree'].getallnodes()[:] # ??
return portage.db['/']['vartree'].getallnodes()[:] # ??
mtimedbfile = os.path.join("/", portage.CACHE_PATH.lstrip(os.path.sep), "mtimedb") # ??
mtimedb = portage.MtimeDB(mtimedbfile) # ??
settings, trees, mtimedb = load_emerge_config() # ??

# should not be needed, as they are catapult internal and there should be no reason to use them in the frontend
for x in portage.portdb.mysettings.pmaskdict[full_name]: # do we need this?
for x in portage.portdb.mysettings.punmaskdict[full_name]: # do we need this?
Properties(dict(zip(keys, portage.portdb.aux_get(ebuild, portage.auxdbkeys)))) # use the get_*_settings?
return Properties(dict(zip(keys, vartree.dbapi.aux_get(ebuild, portage.auxdbkeys)))) # use the get_*_settings?
vartree = portage.db['/']['vartree'] # not needed -> should be handled internally; apps should not need vartree
trees = portage.create_trees(trees=trees, **kwargs) # not needed
settings = trees[myroot]["vartree"].settings # not needed
portdb = trees[settings["ROOT"]]["porttree"].dbapi # not needed

# other
portage.grabfile # write yourself or move into library









Replies:
Re: One backend for all portage GUIs
-- Brian
References:
One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for all portage GUIs
-- Brian
Re: One backend for all portage GUIs
-- Luis Francisco Araujo
Re: One backend for all portage GUIs
-- René 'Necoro' Neumann
Re: One backend for all portage GUIs
-- Brian
Re: One backend for all portage GUIs
-- René 'Necoro' Neumann
Navigation:
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: One backend for all portage GUIs
Next by thread:
Re: One backend for all portage GUIs
Previous by date:
Re: One backend for all portage GUIs
Next by date:
Re: One backend for all portage GUIs


Updated Jun 17, 2009

Summary: Archive of the gentoo-guis mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.