DPS Initial Ideas

[Duane Whitty]

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