From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10711 invoked by uid 1002); 29 Nov 2003 05:01:59 -0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 7222 invoked from network); 29 Nov 2003 05:01:59 -0000 Date: Sat, 29 Nov 2003 06:01:51 +0100 From: Marius Mauch To: gentoo-portage-dev@gentoo.org Message-Id: <20031129060151.69906282.genone@gentoo.org> In-Reply-To: <1070045720.12096.43.camel@ht.gentoo.org> References: <1070045720.12096.43.camel@ht.gentoo.org> Organization: Gentoo Linux X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: H@&[wkk?l:Zx:8i_5bViK&{Vz{c{~r),^&:v/r#+X5dmfA6qCl)~'Ul{"&06Q1[05.%v&c>je5R{=xLnx^=~lN~rO0xuR~~NY)CX\"Nc4$9CBPwDl-.pYuVeGdir86L@\:j?7@%Ej2?Wi-Y0=1]T14ce0w79Bckk[*ti{;iA"{;I}&E~.msRBsBS)N!CS4Gd|_UR Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Sat__29_Nov_2003_06_01_51_+0100_go2N+_oeA1/7+8JA" X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:7e6c91d1b14dbccceb2f2166522fa0f6 Subject: Re: [gentoo-portage-dev] portage-ng requirements doc X-Archives-Salt: 653c4a08-fc39-4541-b61c-a35287600edc X-Archives-Hash: 354bd77b3d78c4cb362412d460bb84e9 --Signature=_Sat__29_Nov_2003_06_01_51_+0100_go2N+_oeA1/7+8JA Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, Some of my points are probably already covered in your list, but let me show my wishlist: portage-ng should be ... - completely based on exchangable components (I don't like the term plugin here as plugins are IMO always optional) and each component should have a well defined interface as well as metadata stating dependencies on other components (e.g. a DB based tree backend needs a DB compatible sync mechanism and parser). - statically typed, so it can be better checked for errors before released. I realize that this might not be possible in several languages, but then at least we should enforce consistent typenames in the API documentation (as currently you often have to read the source to find out what parameter a function really wants). - able to be used as a secondary package manager, this would also include the ability to enable users to install packages in their homedirs using system packages for the dependencies. One important part of this is implementing pathspec. - as secure as possible. This includes signed packages (both source and binary) and automatic priorization of security related updates. That's all for now, but I think my first point implicates many other points mentioned by you. Let me elaborate a bit more by giving an example what components could be used in the current portage: - ebuild parser - metadata parser - profile parser - config parser - packagename/version parser - dependency resolver - rsync sync component - cvs sync component - http sync component (for snapshots) - filesystem portdir storage component - filesystem package database storage component - searching component ... So now the portagesql guys for example could just write different portdir storage, sync and metadata parser components to use mysql as a backend for the metadata instead of re-implementing portage completely. For the dependency example above their storage component would need their sync component or, more flexible, it implements some write() functions that could be used by sync components implementing a suitable interface (but for instance a storage component for cd-rom based snapshots could not do that). I hope you get the idea. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. --Signature=_Sat__29_Nov_2003_06_01_51_+0100_go2N+_oeA1/7+8JA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/yChDWzrL1pM7SNcRAn5WAKCQa+iPCxA8u4kaH14CgJfQqiQmKgCbBCaM ikIz1aCFndQEOXHD27/8MtI= =lOSC -----END PGP SIGNATURE----- --Signature=_Sat__29_Nov_2003_06_01_51_+0100_go2N+_oeA1/7+8JA--