On Sat, 22 Jan 2000, maximum entropy wrote:

> I thought that -current pkgsrc was really only expected to compile and
> run on -current, while users of releases would use the pkgsrc
> distributed with their release.

I think it was said before, that the goal was to, at all times, support:
 o -current
 o the most recent formal release

and to _not_ support
 o older versions of -current, between the last formal release and ``now''
 o older formal releases

There are no release branches or tags in pkgsrc--it simply churns
endlessly.  It is an ``extra'' collection of hacks and tricks that's
useful at any point.  pkgtools/pkg_install, for example, will
automatically update the binary package-processing tools to a version that
works with the packages distributed along with it.  This is necessary
because pkg_* is part of the base src, and users of the last formal
release may need to update it before the latest packages work for them.

Meeting the support-last-formal-release goals involves some flakiness, but
it also has the advantage (over Linux distributions, for example) that the
releases of 3rd party utilities are not forced into apparent
synchronization with NetBSD releases.

A package like GNOME that has a lot of interdependent libraries is a lot
easier to get working on NetBSD-{anything} than it is on Linux. GNOME
RPM's are readily available, but what they don't tell you is that each RPM
has ``depends'' on other RPM's and ``provides'' to other RPM's that must
match exactly w.r.t. version number.  Since some RPM's come with your last
RedHat release and some don't, you end up dipping into your system and
rototilling huge globs of binary.  Sure, you can upgrade the RPM's in your
RedHat release to work with GNOME, but this breaks a bunch of other RPM's
in your release that _also_ depend on those RPM's and want the _old_
version.  

NetBSD gets around this by 
 (1) letting you build source yourself, easing the strictness of
     base<->packages version dependency considerably, 
 (2) minimizing the size fo ``base'' instead of defining it
     to encompass the whole system, and 
 (3) making a (lazy, theoretical) commitment to test the common cases:
     the development version and the last release.

My friend who tried to jump into GNOME early gave up because of this. Most
Linux folk were like him, and simply had to wait for RedHat to bundle
GNOME into their release before they could use it.

This is discussed pretty well on the features page, but I wanted to
mention my own perspective on:
 o how much version-testing work package maintainers should feel obligated
   to perform
 o why this is the right amount.

In this case, my own conclusion would be that if the patches support
-current and 1.4.1, the last formal release, that's good enough.  But
there may be others here who understand our precedent better.

-- 
Miles Nordin / v:+1 720 841-8308 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US