Date: Fri, 11 May 2007 17:28:47 -0400 From: Kris Kennaway <kris@obsecurity.org> To: David Naylor <dragonsa@highveldmail.co.za> Cc: freebsd-hackers@freebsd.org Subject: Re: DPS Initial Ideas Message-ID: <20070511212847.GA30211@xor.obsecurity.org> In-Reply-To: <200705112302.35380.dragonsa@highveldmail.co.za> References: <200705112302.35380.dragonsa@highveldmail.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
--u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 11, 2007 at 11:02:31PM +0200, David Naylor wrote: > Hi, >=20 > Thank you all for your responses, it has given me much to think about. I= =20 > guess there is consenses that there is room for improvement in the curren= t=20 > pkg system. Attached are some of my initial ideas about what is required= and=20 > expected in any (and all future) package systems. =20 >=20 > Since I am going away this weekend I have had limited time to work on thi= s=20 > document and as such it is in early stages of development. My objective = is=20 > to get a clear understanding and target of what is required for this new= =20 > package system. =20 There are a couple of ground rules you need to appreciate: 1) Backwards-compatibility with the ports collection is absolutely required. This may not be an issue for you, but some past proposals have included the phrase "rewrite the ports collection to use tool X". This is pretty clearly a non-starter, unless you also provide a workable (i.e. mostly automated) migration strategy. 2) Integration with ongoing work is required. e.g. we have two people working on extending the existing pkg_tools as part of the google summer of code (including one who is working on integrating the metadata into a berkeley DB database, to attempt to solve the scalability problems we are starting to run into as the typical number of installed packages on a user system grows), and we're not going to throw away their work. 3) Dependencies on new code have a high bar for adoption. i.e. if you propose to bring in new software packages into the base system, you need to definitively prove that they are necessary for solving a serious problem. 4) When people hear the phrase "new package system" they take this as an invitation to pile on feature requests, pet peeves, etc that would be "great to have" in a new package system. While it helps to be aware of these ideas, and where appropriate to avoid designing a system that prevents them from being added, the temptation is to undergo feature creep: the proposal expands to engulf all possible features and ends up collapsing under its own weight (also known as "Second System Syndrome"). Stay focused on a core idea you want to achieve, and you might avoid this problem which has killed the last N serious "new package system" projects. I think your current proposal falls short on points 2) and 3). In particular, I don't see where SQLite is necessary to solve any problems we are currently facing, and your proposal conflicts with existing work. Kris --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGROAPWry0BWjoQKURAuSYAJ9ud5ef3vVtu/8I0t0huKQ7m1lSeACgnRxq EFd+X5rilmdJCNBL/Zr3wto= =Tl9V -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070511212847.GA30211>