Xml in packaging system
Matthew Dillon
dillon at apollo.backplane.com
Sat Nov 1 11:41:46 PST 2003
:I would imagine you could do something like
:%vfsmap -w /pkgbuild /
:
:And after running make install, plists are just
:%find /pkgbuild
:
:This removes the need for
:=2E/configure --prefix=3D/usr/local
:make install DESTDIR=3D/pkgbuild
:
:and programs that dont support these directives. =20
:Thats was my idea of how things would be done. Like gentoo sandboxing, but=
:=20
:much better.
:
:=2DCraig
One can also theoretically run an entire subsystem within a VFS. So,
for example:
login.conf:
...
vfsenviron=stduser.vfs
stduser.vfs might map other .vfs files representing all the ports in the
system in order to produce what the user sees as a complete system.
I am going a bit overboard, but it *would* be possible to do this. In
particular, those VFS's that only do mappings could operate entirely
within the kernel and not represent any significant overhead.
# massive overkill, but a good example:
stduser.vfs {
stdincludes.vfs
stdbin.vfs
stdusrbin.vfs
mozilla-HEAD-run.vfs
openoffice-HEAD-run.vfs
X-HEAD-devel.vfs # development libraries
X-HEAD-run.vfs
}
If you think about it, if even fairly small packages use this sort of
methodology we could institute a standardized 'installation directory'
location for the *physical* location of the files related to a port.
e.g. the files related to a port could be installed in, say,
/usr/local/ports/PORTNAME-VERSION/
And the VFS mapping would map the files and directories in the above
directory to the locations expected by user programs.
Again, this is overkill of an example, but it would work. And that's
what I want to be able to accomplish the most... write a single
mechanism that is flexible enough to support several different sorts
of abstractions.
-Matt
More information about the Kernel
mailing list