Subject: Re: The pkgsrc-2006Q1 branch
To: Anne Bennett <anne@porcupine.montreal.qc.ca>
From: Nathan Arthur <truist@truist.com>
List: pkgsrc-users
Date: 04/01/2006 14:03:26
Anne Bennett wrote:
> But I think that the mental model for the system administration of
> pkgsrc needs to be reviewed, or perhaps simply communicated more
> clearly (I'll be embarrassed if this is on a web page somewhere, but
> if so, I haven't seen it yet).  In that spirit, I'd like to ask the
> designers of the pkg system:
>
>   (a) When audit-packages tells me that an installed package has a
>       vulnerability, what actions do you recommend that I perform
>       in reaction to that report?  (Each package's web page states "If
>       you have a vulnerable package installed on any machine, you are
>       advised to remove the package immediately" - which is not
>       terrifically helpful in practice!)
>   
As a long-time pkgsrc user and friend of a netbsd developer, here's what 
I've come to believe about this problem:

   1. pkgsrc and/or netbsd and/or the developers of either don't have an
      answer to that question.  I think the mental model is: "pkgsrc is
      there to help automate the installation and upgrade of other
      people's software.  It's a convenience, but it doesn't fix the
      underlying software maintenance/upgrade issues associated with
      multiple installed pieces of software that all depend on each
      other.  That problem continues to exist, even in pkgsrc."  Looked
      at that way, I understand the issue.  It's not their fault that
      the developer(s) of software system X bumped the version number of
      a dependency package that is a widely-used package that everything
      else depends on, etc.  That's just a real-life problem with all
      software on all OSes, and pkgsrc doesn't fix it.
   2. The pkgsrc maintainers don't have time to manage this issue for
      all the software in pkgsrc.  It would be an enormous job, and
      they'd be slaves to the decisions of all the external software
      vendors.
   3. You'll notice that the netbsd devs *do* manage this issue with the
      netbsd core software.  Per your comments, they do a good job of
      sending detailed instructions about exactly what you should do
      when core software needs to be upgraded.  In this case, they *are*
      managing the dependency issue for you.
   4. This problem is therefore the full responsibility of the local
      system admin (i.e. you) to sort out, just as if you weren't using
      pkgsrc.  Crappy I know :)

>   (b) When I want to upgrade a particular package (for example because
>       I need its new functionality), how do you recommend that I do
>       this, bearing in mind that I have a lot of other software
>       installed and in use on the system?
>   
There interesting part, now, is that there are semi-viable ways to get 
what you want, but I'm not totally clear on either.  My netbsd-developer 
friend (schmonz) is acting as my surrogate beta-tester for these, and 
I've been hoping that he has good results.  They are:

   1. pkg_views, for packages that support it.  My understanding is that
      pkg_views is a way for multiple versions of the same software to
      be semi-transparently installed on the same machine.  It seems
      complex to configure, but then (I think) easy to use.  But all
      packages don't support pkg_views, and there has been recent
      discussion on this thread about taking it out (!!!).  I haven't
      yet tried it.
   2. pkg_comp, which I've only recently found about (through schmonz). 
      The idea there is that the entire installed-package dependency
      tree can be rebuilt in a "chrooted" environment, so that if it
      fails, nothing is left partially-upgraded or uninstalled, etc. 
      Essentially, "build everything first, and then if that succeeds,
      install it."  This seems like a golden solution, if it works well. 
         1. But it won't fix the core problem that sometimes there just
            isn't a configuration that works: php may not work with the
            latest version of libver, but you need the latest version
            for apache to work, so you can't have both.  If that's true,
            you're just not going to be able to have a self-consistent
            system without using older versions of the software, until
            the developers fix it.  Theoretically, though pkg_views
            could fix that for you :)

Good luck!