pkgviews: The Last Mile

Johnny C. Lam

jlam@NetBSD.org

The NetBSD Project

Outline

• Three typical problems to keep in mind when implementing pkgviews
• Solutions
  • Current solutions and why they suck
  • Newer, shinier solutions to try and test
• Closing thoughts

Updating individual packages

• links-gui-2.1.0.17 is installed on our system.
• links-gui depends on png-1.2.8 and links against libpng.so.3.
• png-1.2.8 has a security vulnerability that's been fixed in png-1.2.8nb1.

How do we secure our links-gui package if we only use binary packages?

Updating individual packages (cont.)

• without pkgviews:
  • Remove links-gui and png packages.
  • Fetch and install the png-1.2.8nb1 package.
  • Reinstall the same links-gui package.
• What's really happening:
  • /usr/pkg/bin/links uses libpng.so.3
  • libpng.so.3 is in /usr/pkg/lib, which is in the rpath
  • png-1.2.8nb1 also provides /usr/pkg/lib/libpng.so.3
  • /usr/pkg/bin/links is unchanged but uses new PNG shared library.

Updating individual packages (cont.)

• with pkgviews:
  • New PNG package must provide shared libraries in a directory already compiled into the executable's rpath.
• Conclusion:
  • There is some fixed location on the filesystem where PNG shared libraries can always be found.

Shebang scripts

• security/amavsid-new installs a shebang script, amavisd that uses the Perl interpreter.
• What is the path to Perl to use for the shebang script?

Shebang scripts (cont.)

• without pkgviews:
  • Perl interpreter is at /usr/pkg/bin/perl.
  • Hardcode this value into the shebang line for /usr/pkg/sbin/amavisd.
• What's really happening:
  • /usr/pkg/sbin/amavisd uses perl
  • We want to avoid invoking the wrong perl executable in the PATH
  • We hardcode the full path to the correct perl executable in the shebang line.

Shebang scripts (cont.)

• with pkgviews:
  • We still want to invoke the correct perl executable, but maybe amongst several installed perl packages.
  • amavisd should work correctly regardless of the Perl version.
• Conclusion:
  • There is some fixed location on the filesystem where the Perl interpreter can always be found.

Plug-in packages

• net/samba has some plug-ins that are used as parts of "extensible" packages:
  • smbspool can be used by CUPS to print to Windows-networked printers
  • pam_winbind.so can be used by PAM to authenticate against against a PDC
• How do we install these plug-ins so that the extensible packages can find them?

Plug-in packages (cont.)

• without pkgviews:
  • CUPS expects backends in /usr/pkg/libexec/cups/backend.
  • PAM-aware packages expect modules in /usr/pkg/lib/security.
• with pkgviews:
  • CUPS expects backends in depotdir/libexec/cups/backend
  • PAM-aware packages expect modules in depotdir/lib/security

Solutions

• Both problems boil down to same conclusion.
• These two problems suggest there needs to be a globally-unique way to refer to files in the latest version of a package.

Solutions (cont.)

• Add latest versions of packages into a global view
  • This is the current implementation using the null view.
  • Should probably use a special view just for this purpose, e.g. "latest"
• Problem: packages can conflict, just like if we aren't using pkgviews.

Solutions (cont.)

• Add latest versions of packages into a ${PKGBASE}-specific view
  • latest-png, latest-perl, etc.
  • Avoids package conflicts, e.g. heimdal and mit-krb5

Solutions (cont.)

• Install part of one package, e.g. plugins, into another package's installation directory.
  • package files are grouped into "bundles"
  • A bundle can be added into the depot directory for another package.
• Pros:
  • Packages don't need to be modified at source-level.
• Cons:
  • Symlinks all over the place
  • Maintenance is hairy, but better tools can fix this

Solutions (cont.)

• Modify sources to find plugins in other directories
  • Current implementation looks for them in null view
  • Should be looking in a ${PKGBASE}-specific view
  • jmmv wants to extend this to use environment variables at run-time to tweak location of plugin directory

Closing Thoughts

• Package views is hard
• Hopefully ready by pkgsrc-2005Q3 if time permits
• Help appreciated!