Subject: Re: goals for NetBSD binary packages
To: Klaus Heinz <firstname.lastname@example.org>
From: Hubert Feyrer <email@example.com>
Date: 04/25/2005 10:21:57
On Sat, 23 Apr 2005, Klaus Heinz wrote:
> What do people expect from binary packages?
Availability & consistency.
Availability on the latest 1-2 official releases (2.0, 1.6.2), and
ideally all platforms that NetBSD runs on. My initial motivation
to start pkgsrc was to get binaries available for NetBSD/amiga.
Aparently that hasn't worked out. I guess some work on cross
compiling would be needed here. Having the fine infrastructure
for that in NetBSD should give a base to start.
Consistency should be given to make sure everything available as
binary pkg can actually be installed, i.e. all dependencies
are there as well. Esp. in (recent) light of security handling,
efforts need to be made to handle things properly. As far as I
know, all the bits are done by individual developers with not
enough communication. I think it would be good if pkgsrc's
management (to which I do _not_ count myself for quite some
time now!) could sort these things out - analyse current and
desired situation, define steps, document and perform them.
I think that pkgsrc is an excellent system for installing software from
source. The "stable" branches are really helpful. There are still "work in
progress" areas like what the right way to update systems are (under
various constraints), but I have faith in pkgsrc developers that these
issues will work out.
Areas that I see in pkgsrc that need attention are:
* better integrate binary pkgs in "release" handling, not only from
the pkgsrc team but esp. with interfacing to operating system
projects like NetBSD (also DFBSD, maybe OpenSolaris at some point).
* Try to get crosscompiling going to some extent - even a 30%-solution
means more pkgs for NetBSD/amiga than we have today!
* Keep overhead low. Try bootstrapping pkgsrc on a slow machine, or
build things there. There's a lot of overhead going into "portability"
across various operating systems (which is nice to have, but not
crucial for NetBSD), which costs performance on slow platforms.
* Documentation. Existing one's scattered across too many places.
Undocumented items include upgrading under various constraints.