OpenBSD Journal

pkgsrc vs ports as viewed by Marc Espie

Contributed by merdely on from the having-everything-that-matters dept.

rgouveia submitted: "As part of the 10 years anniversary of pkgsrc (NetBSD's packaging system), Marc Espie (espie@) was interviewed, among other people. He talks about the inspiration that he takes from pkgsrc, what he likes about it, the main differences from the OpenBSD ports and offers some insight on what pkgsrc may take from the ports tree infrastructure."

From the interview.

What are the main differences between pkgsrc and OpenBSD ports?

[...] Our main goals are binary packages, and reproducibility. With our paranoia, we don't like endless options that make it hard to reproduce issues, so we have a lot less configurability and portability than pkgsrc. It would probably be possible to take the OpenBSD framework and make it run on something else, but that's not a goal, so you would probably have to take a lot of OpenBSD with you. We also have just a few knobs. [...]

Read the full interview on the NetBSD website.

(Comments are closed)


Comments
  1. By Fco. Valladolid (189.130.22.198) ficovh@gmail.com on

    Nice interview, no gives its arm to twist.

    Both packages system are excellent, personally use pkgsrc and ports (from OpenBSD), pkgsrc is plataform independient, and ports depend of a relase in particular.

    I's good that Marc is taking pkgsrc as source of inspiration, this ideas can be very good for ports coming more big in the near future, and NetBSD pkgsrc can be adopt some features from ports.


    Regards.

    Comments
    1. By Anonymous Coward (88.192.78.86) on

      > Nice interview, no gives its arm to twist.
      >
      > Both packages system are excellent, personally use pkgsrc and ports (from OpenBSD), pkgsrc is plataform independient, and ports depend of a relase in particular.
      >
      > I's good that Marc is taking pkgsrc as source of inspiration, this ideas can be very good for ports coming more big in the near future, and NetBSD pkgsrc can be adopt some features from ports.
      >
      >
      > Regards.
      >

      IMHO, the rate port tools and structure change, sucks.
      The fact current ports are usable only on next OpenBSD version is bad.

      Comments
      1. By Anonymous Coward (68.104.220.48) on

        > > Nice interview, no gives its arm to twist.
        > >
        > > Both packages system are excellent, personally use pkgsrc and ports (from OpenBSD), pkgsrc is plataform independient, and ports depend of a relase in particular.
        > >
        > > I's good that Marc is taking pkgsrc as source of inspiration, this ideas can be very good for ports coming more big in the near future, and NetBSD pkgsrc can be adopt some features from ports.
        > >
        > >
        > > Regards.
        > >
        >
        > IMHO, the rate port tools and structure change, sucks.
        > The fact current ports are usable only on next OpenBSD version is bad.

        Many of us feel the opposite way. I find it reassuring that I can be guaranteed that the packages for my release will always work on my release with no dependency nightmares. I for one value stability and correctness over additional flexibility, especially in cases where that functionality is not incredibly useful.

        Also, the most frequent reason you might need to do that is security issues in a package, and those are typically covered quite well by packages version bumps. Feel free to check with the maintainer if you're concerned.

        I just don't see it as a major problem, but I'm old fashioned that way.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]