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