Subject: Re: upcoming anniversary
To: NetBSD/pkgsrc-users <pkgsrc-users@netbsd.org>
From: Jeremy C. Reed <reed@reedmedia.net>
List: pkgsrc-users
Date: 04/30/2007 08:58:55
On Sun, 29 Apr 2007, Georg Schwarz wrote:

> Am 29.04.2007 um 21:34 schrieb Gary Thorpe:
> 
> > Just out of curiosity: what advantages does pkgsrc have over FreeBSD
> > ports?
> 
> compatibility to numerous OSes?

2) I really hate that FreeBSD ports assumes the execution PATH is correct. 
Packages installed may later fail because the PATH was wrong at build 
time. This has happened to me many times for many years and even within 
past couple weeks.

I built a package that came with an example shell script that failed. I 
looked at it and first assumed it was never ported to FreeBSD or tested 
for the package. But then I saw the source came with a template. The shell 
script never was generated correctly because the tools used in it were not 
found because /usr/sbin and /sbin were not in my PATH. Since the package 
installed apparently fine, it is possible I would never have been able to 
debug it without the original source later on.

Other times, the build/install actually failed (such as if trying to do a 
chown or create a user).

3) No consistency with build options. Some packages can be queried and 
some can not. Some have make targets for the options and some don't.

(Note that the ability to save the build options in per-package files is 
useful and interesting. ... which leads to ...)

4) I hate by default that many packages will stop building because they 
are waiting for interactive (menu) input to choose build options.

5) Patches frequently are FreeBSD specific so can't be committed as-is by 
upstream official developers.

6) Patches seem to rarely be submitted upstream. A FreeBSD port may have 
fixed a generic problem years ago but appear to never adequately share 
their fix. (I have seen this several times over several years.)

7) On several occassions on different systems with different versions of 
FreeBSD ports, I have been able to install packages even though existing 
package was already installed -- so now my system was cluttered. (And 
potentially could break production system ... because I assumed that the 
package installation should fail instead of overwriting.) I think this was 
caused by having incompatible (old) pkg_* tools installed.

8) For me, many of the packages required for my professional work and for 
my personal interests are out-of-date (including security fixes) in 
FreeBSD. (One good example is X.org, but I have documented several others 
maybe about 14 months ago in another posting.) Yes, FreeBSD has a lot more 
package offerings but maybe because of that they can't maintain as well 
(so I don't know what is better: a lot of choices versus up-to-date 
choices).

9) Our build wrappers, buildlinking system, et cetera are a huge advantage 
in making sure pkgsrc builds consistently and also that correct ABI and 
API are used for dependencies.

10) Another advantage is that pkgsrc has a dedicated developer that 
compares old and new bulk builds (even for non-NetBSD) and contacts the 
package maintainers about issues. This has been done for at least a couple 
years.

11) Another advantage is that pkgsrc has a person *scheduled and assigned* 
to handle and/or assign new Bug reports. (Maybe FreeBSD has that, but I 
don't think so.)

... I have another list of good things about pkgsrc (such as pkgsrc 
security team) also available online ... but I stop here.

I have used FreeBSD plus ports for about the same amount of time that I 
have used NetBSD and pkgsrc. I have a lot more experience with NetBSD and 
pkgsrc ... nevertheless I use (and will continue to use) FreeBSD and Ports 
a lot more professionally (my customers pay me). I have built ports for 
FreeBSD Ports also so I am familiar from that point-of-view also. Just so 
I am not too biased to NetBSD and pkgsrc: FreeBSD is an excellent 
operating system and FreeBSD Ports is a great way to install a huge amount 
of software. (I am glad I have a freedom of choice based on my own 
personal and professional experiences.)

  Jeremy C. Reed