Slashdot Mirror


NetBSD Branches pkgsrc-2005Q1

jschauma writes "NetBSD's Alistair Crooks has announced the availability of the new stable branch pkgsrc-2005Q1 of the NetBSD Packages Collection (aka pkgsrc). This branch includes all the updates to the thousands of existing and additions of hundreds of new applications since the hereby obsoleted pkgsrc-2004Q4 branch. Some noteworthy infrastructure changes applicable to all 13 operating systems for which pkgsrc is available include the support for multiple digests to check the integrity of the distribution files as found on the Internet (triggered by the recently-found problems with the SHA-1 algorithm) and the so-called alternates framework."

3 of 29 comments (clear)

  1. Binary packages? by Anonymous Coward · · Score: 2, Insightful

    Where are the binary packages for pkgsrc-2005Q1? I can't find them on ftp.netbsd.org.

    1. Re:Binary packages? by jschauma · · Score: 4, Insightful

      Binary packages will be uploaded as soon as the various bulk-builds on the different operating systems and NetBSD ports have completed. This takes a while on some older platforms, though I'd expect some of the faster platforms to soon upload.

      --

      -- "Tradition is the illusion of permanence."
    2. Re:Binary packages? by jschauma · · Score: 2

      From what I read here, I understand that 'pkg_add -r' automatically updates the given package and all of its dependencies. It's not quite clear to me, though, what exactly that means. After upgrading a given package, does it: (a) upgrade each package that depends on this one to the latest available binary package? (b) upgrade only those packages that rely on the newer version (for example, for ABI changes) but leave others (the ones that will work perfectly fine with the older version as well as the newer) alone? (c) only update the given package and reshuffle dependencies so that all packages that used to depend on foo-old now depend on foo-new?

      (a) has the following problems: what if binary packages for all dependents are simply not available? Leave the old packages in place? What if it's known that the depending package will not work with the newer to-be-installed one?

      (b) would be great, but is very difficult, I think. It requires that the binary package contains information about a large number of other packages and how they may or may not work together.

      (c) is trivial (for pkgsrc (not binary packages) that would be 'pkg_add -u'), but has the same problems as 'make replace'.

      pkgsrc approaches (b) by the use of so-called recommended vs required dependencies. (Again, for pkgsrc, though binary packages built with IGNORE_RECOMMENDS can be forced to be installed.)

      If I want to upgrade, say, kde3 (*shudder*) from binary packages, I'd simply run 'pkg_add -u kde3' -- ie, I'd start at the leaf package and let it pull in all dependencies. This is not the same as starting with a package somewhere in the middle of your dependency-tree, but it has a much clearer solution. Rippling downwoards through a dependency-tree from the middle is obviously difficult ('make update' does that if building from pkgsrc instead of using binary packages).

      I may be mistaken, but I don't think that NetBSD's pkg_add has the functionality to do that -- presumably just b/c people haven't figured out what The Right Thing To Do is exactly. On the mailing lists, pkg_chk and pkg_comp are usually suggested to perform these tasks.

      --

      -- "Tradition is the illusion of permanence."