On Friday, 11 May 2007 at 17:28:47 -0400, Kris Kennaway wrote: > On Fri, May 11, 2007 at 11:02:31PM +0200, David Naylor wrote: > > Hi, > > > > Thank you all for your responses, it has given me much to think about. I > > guess there is consenses that there is room for improvement in the current > > pkg system. Attached are some of my initial ideas about what is required > > and > > expected in any (and all future) package systems. > > > > Since I am going away this weekend I have had limited time to work on this > > document and as such it is in early stages of development. My objective is > > to get a clear understanding and target of what is required for this new > > package system. > > 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
Kris, In your opinion what is the biggest problem(s) the ports system and the package building system currently face? Is this a common problem, i.e., is the issue facing building from ports the same as installing from pre-built packages? I ask this in the context of infrastructure as opposed to any tools currently being used. Is it hoped / planned that storing the metadata in a berkeley DB database will help with the parallelization of package building? If only one thing was going to be done to improve the ports system, not including drafting more volunteers :) , what would you recommend that one thing be? Duane _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"