Re: Re: ebuilds in XML

--===============051243804107493629==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-dV+nR1rWc653a4mUUi5c"


--=-dV+nR1rWc653a4mUUi5c
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

gerk,
looks good! here are some thoughts i had while reading (mostly on code
design).

- 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.

- 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.

- 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.

- 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.

sorry if any of the above in unintelligible. i've yet to get a cup of
coffee.

good morning everyone.
nall.


On Mon, 2003-06-30 at 00:39, mark guertin wrote:
> Ok, i finally got down to it and put some of the directions we have=20
> been discussing for this, and it's linked off of my Wiki page:
>=20
> http://wiki.zynot.org/zynot/moin.cgi/MarkGuertin
>=20
> I think this may be a good starting point for us on this stuff, not too=20
> ambitious, but a good basis for proof of concept stuff too.
>=20
> P.S. Please comment :)
>=20
> Gerk
>=20
> _______________________________________________
> Zynot-pkgmgr mailing list
> [email protected]
> http://lists.zynot.org/mailman/listinfo/zynot-pkgmgr

--=-dV+nR1rWc653a4mUUi5c
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/AEfT4DLJUYqFxU0RAsD8AJ4jm+Km/5v0W/uJSV9ICiAxZjAhvwCcD7uY
0a75pmRVtoOQs/+A4qoosEI=
=I3dV
-----END PGP SIGNATURE-----

--=-dV+nR1rWc653a4mUUi5c--


--===============051243804107493629==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Zynot-pkgmgr mailing list
[email protected]
http://lists.zynot.org/mailman/listinfo/zynot-pkgmgr

--===============051243804107493629==--