fe3c1321bf
to tech-pkg: ===== * USE_BUILDLINK3=YES will be unconditional. (In fact, USE_BUILDLINK3 will be ignored altogether by mk/; but see below.) * NO_BUILDLINK and NO_WRAPPER will be ignored by mk/. If a build happens, these phases will happen. * The existing NO_BUILD will imply the previous NO_BUILDLINK and NO_WRAPPER. If no build happens, those phases are not needed. * NO_TOOLS will be ignored by mk/. The tools phase, which provides much more than just the C compiler, will always happen regardless of package. This will make metapackage builds only slightly slower, in trade for far less user error.
140 lines
6.1 KiB
Text
140 lines
6.1 KiB
Text
$NetBSD: README,v 1.6 2005/03/24 17:46:01 tv Exp $
|
|
|
|
0 Package Views
|
|
===============
|
|
|
|
Package views is a pkgsrc technology that supports building and
|
|
installing multiple versions of the same software such that they
|
|
co-exist on a single system. Individual packages are installed into
|
|
their own directory tree and their files are symlinked into "views".
|
|
Users can choose amongst different software collections provided by
|
|
different views by appropriately setting shell environment variables,
|
|
e.g., PATH, MANPATH, etc.
|
|
|
|
Package views is similar in spirit to the Encap Package Management
|
|
System, the GNU Stow Project, and the Carnegie Mellon University Depot
|
|
Configuration Management system:
|
|
|
|
http://www.encap.org/
|
|
http://www.gnu.org/software/stow/stow.html
|
|
http://asg.web.cmu.edu/andrew2/depot/
|
|
|
|
However, these projects have a philosophy of "install anywhere, use in
|
|
one place", whereas package views departs from that model with a
|
|
philosophy that can roughly be summarized as "install in one place,
|
|
use anywhere".
|
|
|
|
|
|
0.1 A short history of package views
|
|
====================================
|
|
|
|
Package views was proposed as a solution to the problem of not being
|
|
able to install multiple versions of the same software simultaneously
|
|
via pkgsrc. Alistair Crooks presented a paper on package views at
|
|
EuroBSDCon in November 2002 that described the work he did on the
|
|
"pkgviews" branch of pkgsrc where he implemented his ideas. The paper
|
|
is highly-recommended reading for a more complete understanding of
|
|
package views principles and is available at:
|
|
|
|
http://www.NetBSD.org/Documentation/software/pkgviews.pdf
|
|
|
|
Unfortunately, Alistair ran out of time to devote to integrating his
|
|
work into the main pkgsrc branch. The code he developed languished on
|
|
the "pkgviews" branch for over a year, and in the meantime much code
|
|
was added to pkgsrc that increased the complexity and the capabilities
|
|
of pkgsrc, including buildlink2, which conflicted with Alistair's
|
|
implementation of package views. In September 2003, Johnny Lam
|
|
integrated the functionality on the pkgviews branch into modern
|
|
pkgsrc. As part of the integration, a new buildlink3 framework was
|
|
created so that the ability to isolate builds from differences in
|
|
the environment wouldn't be lost.
|
|
|
|
|
|
0.2 Package views terminology
|
|
=============================
|
|
|
|
The terminology for packages in the package views world is as
|
|
follows: a "pkgviews" package is a package that has been converted to
|
|
build and install using package views. An "overwrite" package is one
|
|
that hasn't. A "depoted" package describes a pkgviews package
|
|
installed into /usr/pkg/packages in its "depot" directory. A package
|
|
"instance" in a view describes a depoted package symlinked into a
|
|
view.
|
|
|
|
|
|
0.3 What's been done
|
|
====================
|
|
|
|
The pkg_install tools have been enhanced to handle both binary depoted
|
|
packages and binary "overwrite" packages. The pkgsrc internals have
|
|
been modified to allow building and installing depoted packages and to
|
|
automatically add a depoted package in the default view.
|
|
"Overwrite" packages shouldn't be affected by the changes, and can be
|
|
freely mixed with pkgviews packages.
|
|
|
|
Packages that have been converted to use "pkgviews" should add the
|
|
following line to their Makefiles:
|
|
|
|
PKG_INSTALLATION_TYPES= overwrite pkgviews
|
|
|
|
PKG_INSTALLATION_TYPES can also just be one value or the other to
|
|
explicitly note that the package only supports that one type of
|
|
installation style. Users may add the following line to /etc/mk.conf:
|
|
|
|
PKG_INSTALLATION_PREFS= pkgviews overwrite
|
|
|
|
to note that they prefer building using pkgviews if the package
|
|
supports it, otherwise to build using the "overwrite" installation
|
|
style. However, users should not change PKG_INSTALLATION_PREFS from
|
|
the default value unless they're sure that they want to start
|
|
migrating their package system over to using pkgviews. The default,
|
|
"overwrite pkgviews", will cause all packages to build using the
|
|
"overwrite" installation style.
|
|
|
|
Some highlight of pkgviews packages include:
|
|
|
|
* fully dynamic PLISTs
|
|
* multiple versions of the same package can co-exist
|
|
|
|
|
|
0.4 buildlink3 pkgsrc build framework
|
|
=====================================
|
|
|
|
A new buildlink3 framework that takes advantage of depoted packages
|
|
has been added to pkgsrc as part of the package views changes.
|
|
Buildlink3 uses wrapper scripts much like buildlink2. However, when
|
|
building pkgviews packages, it doesn't symlink files into
|
|
${BUILDLINK_DIR} since it can safely refer to only a specific
|
|
package's files by passing the appropriate -I<dir> and -L<dir> flags
|
|
to the compiler, where <dir> points to a location in the package's
|
|
depot directory. When building "overwrite" packages, buildlink3 will
|
|
act and feel very much like buildlink2 but with more advanced wrapper
|
|
scripts, and there are provisions for allowing an "overwrite" package
|
|
to build against the viewed instance of a depoted package. The
|
|
implementation currently allows "overwrite" to depend on either
|
|
"overwrite" or pkgviews packages, but pkgviews packages are restricted
|
|
to only being able to depend on other pkgviews packages.
|
|
|
|
|
|
0.5 Future Work
|
|
===============
|
|
|
|
There may be some way around the problem of pkgviews packages not
|
|
being able to depend on "overwrite" packages. That's the only thing
|
|
standing in the way between allowing an arbitrary package to be built
|
|
using either installation style and working seamlessly with any other
|
|
package. The problem has to do with proper handling of metadata in
|
|
the +REQUIRED_BY and +CONTENTS files that are split in two separate
|
|
places. One possible route to a solution is that for each overwrite
|
|
package, we can symlink /usr/pkg/packages/<pkg> -> /var/db/pkg/<pkg>.
|
|
This allows depoted packages to record themselves directly in the
|
|
+REQUIRED_BY files of "overwrite" packages. If a user happens to run
|
|
|
|
pkg_delete -K /usr/pkg/packages <overwrite_pkg>
|
|
|
|
then it still uses the correct +CONTENTS, +INSTALL, and +DEINSTALL
|
|
scripts, so the package will still remove itself properly from
|
|
/usr/pkg. However, there are some remaining issues with properly
|
|
removing both the /var/db/pkg/<pkg> directory and the
|
|
/usr/pkg/packages/<pkg> symlink, so the deletion won't be completely
|
|
clean until this issue can be resolved.
|