DragonFly kernel List (threaded) for 2003-11
Re: Xml in packaging system
:Well, I think it would only record changes to the vfs layout - not
:every action you took, like a screen-scrubber would.
:But I'm confused too. Wouldn't entire files be sucked into the file
:build_depends.vfs? How would you tell it that /usr/local/lib/foo.a
:is just a dependency, to be built by some other port/package as a
:prerequisite, and not something to be created outright by the 'patch'?
:At any rate, I guess this means slogging through the meaty stuff will
:have to wait until VFS is working. But, it doesn't address the other
:details about ports/packages - metadata, file format, and so forth, so
:we still have plenty we can bikeshed about in the meantime :)
There are two things going on:
(1) Dependancies are other VFS-generated blah.vfs files. They would be
'mapped' into the current VFS as a dependancy, not actually copied
into the current VFS.
(2) The only 'top-layer' modifications made to the current VFS, other
then the mappings in (1), would reflect *ONLY* the requirements of
the current package.
build time: mappings + package source code + the modifications
that were made to get it to compile on DragonFly.
install time: possibly additional mappings required to install
(e.g. one might need 'perl' to install a third
party package but the third party package itself
doesn't need perl at run time)
run time: A totally different set of mappings + package
Lets take the build-time situation first, since it makes a great
example. Lets say you are building mozilla.
* Mozilla depends on other libraries, which you have already
generated ports for. So you just 'map' these library
dependancies in for the purposes of doing the build.
* The Mozilla base source for version XYZ is distributed by a
third party. You create a port that represents the broken-out
base source (which can then be abstracted at a higher level
to mean 'pull down this mozillaBLAHXYZ.tgz from host FUBAR and
tar xvzpf it').
Call it: mozilla-base-XYZ
* With the base source available as a port you can simply map it
in. Now you 'modify' the base source to make it compile under
Call it: mozilla-dfly-XYZ
The 'patch set' for mozilla-base-XYZ would be zippo because we would
have a VFS option to 'tar xvzpf' the archive into the VFS's memory
filesystem, so this devoles into a fetch-like entity similar to what
we see with the FreeBSD packages system.
The 'patch set' for mozilla-dfly-XYZ would represent only the
modifications we have made to the source base in order to get it to
compile on DragonFly.
So, as you can see here, I am attempting to make things as easy as
possible for the person responsible for doing the port and, also,
I am attempting to make things as easy as possible for anyone who wishes
to maintain the port. Maintaining the port can be as simple as
loading up mozilla-dfly-XYZ VFS, making *additional* modifications,
and then just telling the VFS to save its state again. i.e. no messing
with manual patch set generation just to make a small change here and
there like has to be done with the FreeBSD ports system.