tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkgin suggesting pkg downgrade?



Jonathan Perkin <jperkin%pkgsrc.org@localhost> writes:

> "How else do you then deal with vulnerabilities like this in a timely
> manner" is technically easy, you just have continuous bulk builds that
> churn out daily package updates as I've done for many years, but
> politically very very very hard.

That's one approach and certainly reasonable.  There are two others:

The current approach with pkgsrc binary packages is to have a stable
branch, and for security fixes to be applied to the stable branch, and
then you can update to them.   There is latency, but not necessarily all
that much.

Another is what I do: for each os/version/arch that I run, I have a
build machine (mostly domUs, sometimes the primary/bigger instance of
that type), and I keep it up to date with the quarterly branch.  If I
want something updated, I either apply a change to the branch or flip
that package to -current, make replace and pkg_rr, create a summary
file, and either make available over remote filesystem or sync the
binary packages, and then pkgin.   This works for changes I want that
aren't appropriate for a stable branch.


The real difficulty is that for N people, there are 2N+1 definitions of
stable, meaning which changes are wanted, and on what time scale, and
which changes are specifically not wanted.  It's not going to be
possible to please everyone, but the focus on building from source makes
it easier for people to do custom things.  I think there would be great
merit in finding clusters of opinions and having points in the choice
space that are good enough to make larger numbers of people happy.


Home | Main Index | Thread Index | Old Index