My comments below ...

> > pkgsrc tree is "10 Sep 2001" (which I assume is "stable" for 1.5.2).
> > (Please feel free to tell me other tags or other ways to fetch "stable" pkgsrc.)
> 
> Sorry, there is no "stable" pkgsrc -- there's no branching at all. Even
> rolling back to the netbsd-1-5-PATCH001 tag, the last released "pkgsrc",
> won't necessarily help you if you've already installed packages built
> from newer pkgsrc, although that would otherwise be your "stable" tag.

I misunderstand this. I thought that there is a freeze of the pkgsrc right
before a release is done so that the pkgsrc for that release can be
considered "stable".

I chose that date -D "10 Sep 2001" because it corresponded with the last
release. (I guess I should have used "-r netbsd-1-5-PATCH002" instead.)

> The best we can do is to resolve not to do it again. Maybe for 1.6* we
> should consider going back to separate collections for 1.6, 1.6.1, and
> so on, so at least we have a chance to gloss over certain mistakes, and
> still produce one single consistent collection of binary packages.

What were some reasons that was stopped?

What can be done to create a "stable" pkgsrc branch?

This stable branch will only be updated when:

 - a problem with dependencies/requirements were noticed (and a dependency
   needs to be changed, such as a version number incremented);

 - a serious bug is found and the package needs to be patched;

 - a new official stable release of NetBSD is being made (such as 1.5.2 to
   1.5.3 or 1.5 to 1.6).

This stable branch will not be updated:

 - to add new packages;

 - to patch current patches for enhancements or bug fixes other than
   serious security issues.

The benefits of having a "stable" pkgsrc branch:

 - users who use CVS for pkgsrc (unless they purposely want current) won't
   have conflicts with binary packages fetched from FTP servers;

 - the stable branch will become better and better over a few weeks --
   without any issues of adding newer packages; there should be no
   conflicts (which is now very common with regular up-to-date pkgsrc);

 - admins can easily track the stable branch to keep up-to-date with
   security fixes without worrying about problems with current
   dependencies.

Some problems with a stable pkgsrc branch:

 - need volunteer(s) to care for it;

 - updating entire "stable" collection to current pkgsrc may be a lot of
   work. But maybe not -- require (or suggest) that any change to stable
   must have a similar and appropriate change for the current collection;
   i.e. if stable's apache pkgsrc is patched for a minor security issue
   and the current version of apache pkgsrc is upgraded to later version
   (which also includes security fix), then you don't have to worry about
   it.

Can someone setup a branch for pkgsrc that has a purpose of rarely being
changed? (Should I send-pr this?)

(I know I have mentioned this before.)

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