Re: Re: ebuilds in XML

mark guertin <[email protected]> Mon, 30 Jun 2003 12:59:23 -0400
Newsgroups gmane.linux.zynot.general
Message-ID <[email protected]>
On Monday, June 30, 2003, at 10:23 AM, Jon Nall wrote:

> - do we ever want to get metadata from somewhere besides the XML files
> (i'm thinking of an import of a gentoo ebuild)? if so, we should
> properly abstract this -- a MetadataParser object from which an
> XMLMetadataParser (and others, EbuildMetadataParser, etc) derive. in
> either case, i'd like to see this as a standalone python class that can
> be used by portage.
>

Hmm yes this is definitely a possibility.


> - re: local databases, in this phase we should implement (at least) a
> flatfile DB and a SQL based one. this should help us get kinks worked
> out for what we want the abstract interface to be. again, i think this
> stuff should be implemented as a python classes that are usable by
> portage proper (eg: PortageDatabaseAPI from which
> FlatfilePortageDatabaseAPI and MysqlPortageDatabaseAPI are derived).
> those long class names are only for clarity. making portage more 
> modular
> is a Good Thing.
>

Yep agreed there for sure.


> - the 'hook' for security updates is in my mind completely separate 
> from
> portage. just a little daemon listening on a port should suffice, 
> right?
> it can spawn whatever it likes when something tells it to. the other
> option is to add a server component to portage and let the portage
> engine be a daemon. i've considered this path before, but it would
> require pushing a good amount of the functionality of emerge into the
> portage module due to performance reasons.
>


hmmm ok.  I will trust your better judgment on this.  I just feel 
strongly that this funtionality has to be there.  Would this external 
app also be able to revoke ebuilds and such?  This is a crucial part of 
this strategy as well.


> - i agree that the versioning stuff is absolutely critical. i assume
> we'll just put the rev of the build that the XML was generated from in
> the XML and pull that rev from cvs/svn. that will require a fair load 
> on
> the cvs/svn server though and we may need to look into something like
> CVSup.
>

Yep, and hopefully by the time we have things implimented and are 
starting to feel the strain of it that someone has made a working CVSup 
port for ppc ;)

Gerk