Subject: maintaining binary pkgs on the ftp server
To: None <tech-pkg@NetBSD.org>
From: Hubert Feyrer <hubert@feyrer.de>
List: tech-pkg
Date: 07/04/2007 13:05:38
I was musing about our binary pkgs on ftp.NetBSD.org (and mirrors!) the 
other day:

Right now, the situation WRT binary packages in large is:

  * developers build & upload binary pkgs (which is good!)
  * pkgsrc-releng moves vulnerable packages around (which is also good)
  * there are several sets of binary packages for a number of
    pkgsrc releases, operating systems, operating system versions and
    hardware archirectures (which is actually the goal go provide)
  * NetBSD's documented way of finding binary pkgs for OS X, Arch Y in
    /pub/NetBSD/packages/X/Y is broken as the upload process is
    non-working, and noone looks into fixing either the process or the
    links (manually)
  * Old sets of binary packages rot away.
    1) Noone knows what the latest set of binaries for OS X, Version Y,
       Arch Z is, let alone what pkgsrc version it is available from,
       without looking.
    2) Due to this, nuking all "old" binary pkgs may remove the last binary
       pkgs for a non-popular platform
    3) Mirrors run out of disk space due to this, leading to non-functional
       mirrors.

What I'd like to see is to coordinate binary pkgs in the large:

  * get an overview of what's there
  * coordinate/talk with developers uploading binary pkgs
  * make sure reality reflects NetBSD documentation (or vice versa)

    Documentation in this place would be the examples in pkg_add.8,
    pointing at /pub/NetBSD/packages/$OS_VERSION/arch

  * document what's there, answering questions like
     - where can I find latest binary pkgs for NetBSD/i386 4.0
     - where can I find latest binary pkgs for Solaris 9/x86
     - where can I find (any) binaries from pkgsrc-2007Q2
  * nuke/"archive" old binary pkgs
  * establish and document the policy for this

    Suggested place for that documentation: Near
    http://www.netbsd.org/docs/pkgsrc/ftp-layout.html (which currently
    doesn't have a lot of useful information)

Anyone up for that job? :)


  - Hubert