Re: The ports-system and userland in general.

[Weapon of Mass Deduction <blacklist@xxxxxxxxxxx>]

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.
>
> --Devon

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. ;)

--
Greetings,
WMD (tfa . x @ inter . nl . net)