DragonFly BSD
DragonFly users List (threaded) for 2004-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: The ports-system and userland in general.

From: "Devon H. O'Dell" <dodell@xxxxxxxxxxxxxxx>
Date: Tue, 14 Dec 2004 18:20:26 +0100

Weapon of Mass Deduction wrote:
Hello all,

I remember Matthew explaining he's looking for
a better alternative to NetBSD pkgsrc for the
ports-system, as a reaction to some people
proposing pkgsrc.

I'm currently thinking out a good userland
architecture, so I would like to know what
qualities he or others is/are especially looking
for then.

This also applies to the userland. Of course
something about this is already written down
at http://www.dragonflybsd.org/goals/userapi.cgi ,
but that article focusses on the programmatic
plans, not too much on the functional.

There have been miscellaneous discussions / arguments / bikesheds about this subject on IRC and on the lists. Simon (corecode) has done some research into it; Will_D has as well, and there are obviously efforts of other parties to get pkgsrc working with additional DragonFly-specific functionality (as I understand it).

At this point, I can't say that anybody has definite goals. All people have different ideas about what a perfect package manager should do. If you're interested in making one, there is a link on the Wiki to some discussion and research about this.

The concensus seems to be:

    o It shouldn't be ports
    o It should be made ground-up
    o It should allow multiple versions of a program to be installed
    o It should allow for easy upgrades
    o It should allow for source building and binary packages

Simon (corecode) has ideas about the format needed to store information about the packages. I don't know much about this, but it's something that seriously needs reworking.

There may be more points, but I don't know what they were. Something that would be interesting would be a way to port files from pkgsrc or ports (or other build systems) over to Whatever Build System, which would reduce the need to manage $BIGNUM files with such a small team.

I think the best idea is to get started on something and, when you've got something working, talk about it. If it works well, other people will use it. Maybe it'll be incorporated as our ``official system''. Maybe not. But at the least it'll be a good idea of what works and what doesn't.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]