On Fri, 14 Sep 2001, Gan Uesli Starling wrote:

> # cd /usr/pkgsrc/x11/gnome
> # make fetch-list > list2fetch.sh
> # sh -x list2fetch.sh
> # make

I see you run make right after doing this fetch-list; you don't need to do
this, because make will simply do it for you. (Using the fetch-list is
useful if you need to download the source at a different time than
building it.)

> ===> Required package autoconf>=2.50: NOT found
> ===> Verifying reinstall for ../../devel/autoconf
> ===> Installing for autoconf-2.13
> ===>  autoconf-2.13 is already installed - perhaps an older version?

So what package required this autoconf? But I guess that doesn't matter
...

> ...then went to look for autoconf-2.5 or higher. But netbsd.org's
> software listing for ../devel/autoconf shows only version 2.13. 

From looking at the CVS history for it, autoconf package used to be at
version 2.52; then on Aug. 28, it went back to 2.13: "Backout upgrade of
autoconf by popular demand." -- which indicates this was discussed
somewhere.

That is one of the problems with package source collection, because
often the latest collection via cvs is beta or development and
sometimes the versions don't match up. The collection as released with an
official release should be "stable" or shown to have the package
dependencies to match up.

Using Debian as an example, they have a stable package collection that is
used for years. They test and test and test to make sure that the packages
all work together. By the time it is stable, the software is often
out-of-date. The only changes they ever make to this stable collection is
for very minor fixes and for security/bug fixes.

Debian also provides a testing packages system with up-to-date software,
but some of the packages don't work right or work together. But after a
lot of testing (which includes freezes to stop new changes), it will
become the new official release. But then this new "stable" collection
will possibly be out-of-date, but will work very good. (And the cycle
continues.)

This is very similar to NetBSD's system, other than one minor but
significant difference: NetBSD's package system doesn't have a stable
branch for security, minor bug, and package compatibility fixes. Because
it doesn't offer a stable branch (other than what is official at a time of
an official release), the pkgsrc collection is in a state of continuous
changes. So if you need to update to a newer package for some important
security fix, you may need to upgrade from the stable pkgsrc collection to
the testing collection -- and then it may have some dependencies that are
broken or entirely incompatible with your current and perfectly working,
stable, package system.

By the way, there are a couple systems that do bulk builds of the pkgsrc
collection (every day I think); it reports on what packages couldn't be
built (because of broken depends for example) so problems can be fixed.

I believe there should be a stable branch for the pkgsrc collection that
only allows changes that are required for security fixes (which in many
cases may mean patching the old version instead of upgrading to a newer
version) or to fix minor packaging problems -- so in other words, this
pkgsrc collection would always work. (Basically, this takes a few people
who are willing to spend time to maintain this.)

(This email seems more appropriate for tech-pkg.)

> So I searched GNATS, and found nothing on it. Then I filled out a
> send-pr on it. Hope I filled it out right.

Also be sure to look at the cvsweb and have a look at the cvs logs.

   Jeremy C. Reed
   http://www.reedmedia.net/