DPS Initial Ideas

[Kris Kennaway]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20070511/f8100b95/attachment.pgp