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.

To: "Devon H. O'Dell" <dodell@xxxxxxxxxxxxxxx>
From: Weapon of Mass Deduction <blacklist@xxxxxxxxxxx>
Date: Tue, 14 Dec 2004 22:05:57 +0100

Hey Devon,

First of all: I promise - I will join the IRC soon. :)
I'm just too busy with other activities (like lurking
on the DragonFly-BSD-newsgroups :P) at the moment.

When the NetBSD pkgsrc-freeze is over, I will install
an IRC-client to chatter a bit with you blokes. :)

I speak English, Dutch, but also German quite well, so
I'm all set. >:) :+

Devon H. O'Dell wrote:
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

Conforms totally to my vision, and mine to yours logically. If all you guys already agreed on these points, I'm sure we will get far!

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.

I certainly have, but it might not be supported by everyone (immediately)... :)

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.

Yes indeed, I also thought about that one. Real-time conversion will be - as I see it now - not problematic.

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.


Well, when I read your posting it certainly raised my enthousiasm!
I thought my vision(s) were perhaps a bit too radical, concluding from
the calls for pkgsrc-adoption. But the points you describe, were exactly
the ones I thought of. Problem was (and is) more: aren't there other things then? :)
Because the project looks a bit like a void (not the C one :D) this way.
Open ended, is maybe a better word. But trust me, I'm a guy that gets
things done, I will write out the most ambitious plans happily. :D

Interesting note: I might very well call this a 'study-project', which
means I will have plenty of time to dedicate myself to it. I already see
it in front of me: 'international cooperation', 'revolutionary project',
'high-level UNIX-development', etc. Not that it necessarily will be that
way, but just to convince them. ;)

WMD (tfa . x @ inter . nl . net)

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