Subject: Re: separate "stable" collection (was Re: pkg/14284: xv-3.10anb1
To: None <email@example.com>
From: David Brownlee <firstname.lastname@example.org>
Date: 10/19/2001 18:31:54
We've been around this loop before. Given enough resources a
-stable pkgsrc branch would be wonderful, however until someone
decides to pay a developer full time, its not going to be realistic.
This is distinct from tagging pkgsrc, which is already done.
We are working towards producing regular bulk-builds of pkgsrc
for each major release and platform. Anyone interesting in helping
is invited to subscribe to email@example.com.
David/absolute -- www.netbsd.org: No hype required --
On Thu, 18 Oct 2001, Jeremy C. Reed wrotee:
> > > 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
> 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
> 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.)