DragonFly BSD
DragonFly kernel List (threaded) for 2003-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Xml in packaging system

From: Galen Sampson <galen_sampson@xxxxxxxxx>
Date: Fri, 31 Oct 2003 11:32:59 -0800

Matthew Dillon wrote:
What I envision in a packaging system is something that makes the port maintainer's life as easy as possible.

    Lets say you are developing a new port, libabcd, which depends on a
    number of other libraries which are also ports in the system.

As a developer I want to be able to do something like this:

% vfsenvironment empty 'csh'

    (Now you would be in a vfs-sandboxed shell.  You can map-in other ports
    which you have already installed on the system):

    % vfsrecord "build_depend"
    ok, recording mappings as 'build_depend'
    % vfsmap libgettextsrc:0.12.11
    % vfsmap libexpat		(map in the highest installed version)
    % vfsmap libc
    % vfsmap gmake
    % vfsrename /usr/local/bin/gmake /usr/local/bin/make

    Once you have built an environment you could then attempt to build
    your new port natively simply by running the port's native build
    (at least initially).  If things are missing you can vfsunmap and vfsmap
    additional required elements.

    Modifications to the port distribution itself could also be done through
    the VFS.  In this case the VFS would be acting like a unionfs in that it
    would record whiteouts (deletions) and copy files that are modified into
    a higher layer which would be stored in the VFS environment process's
    memory (sufficient as long as no more then 2G worth of changes are made).

% vfsunion ~dillon/original_distribution work

(make your modifications to the work. edit files, rm files, rename, whatever).

    When you are satisfied that the build is working you can save the vfs
    state, which will also 'diff' any modifications you have made and record
    file/directory deletions.  The output file would be human readable and
    human editable (though it's easier for the developer to just enter the
    vfs environment and make modifications within the environment)

    % vfsrecord -w
    all changes recorded in 'build_depend.vfs'
    % exit


    Ok.  So there you have it, you now have the VFS environment and the
    patches required to build your new port!

Similar action would be taken for install and run-time dependancies.
Run-time dependancies would be more restrictive since under normal
conditions you might not want to have to run every port wrapped in a VFS. e.g. simple ports like when you run 'less'. But more involved
ports, like OpenOffice, might always run in some sort of VFS environment.

    Note that the VFS environment I am contemplating does not take over
    the entire filesystem space.  That is, in the above example, the mainstream
    directories /usr/local/lib and /usr/local/bin would be selectively enabled
    and/or modified within the VFS but other directories, like your home
    directory for example (really all other directories not involved with
    mapping operations) would simply be passed through.  You would have to
    explicitly tell the VFS to map something as a union in order for the VFS
    to record your modifications within that target.

    In anycase, that is my idea... to approach it from the port maintainer's
    point of view rather then from a technical standpoint.

This is excellent. What you have described here describes the build configuration. You mention that the install dependencies would be similar. My question is about package lists. When I install this port that I have set up would the package list stay static like the pkg-plist, or would it be possible to be dynamic (i.e. record what is installed and save that is the package list). Say I'm about to `make install` or equivalent for this port I'm creating (libabcd in your example). I assume it would be something like:

% vfsenvironment install_depend.vfs 'csh'
(Read in the environment that is required for installation of libabcd)

% vfsrecord "install"
% vfssnapshot ${PREFIX} install.vfssnap

Record current state of ${PREFIX} and save it in install.vfssnap for `diffing` after install.

% make install
% vfsunion install.vfssnap ${PREFIX}
% vfsrecord -w
all changes to ${PREFIX} recorded in 'install.vfs'
% exit

The reason a snapshot would need to be recorded is I can't vfsunion to something that doesn't exist yet. Maybe instead of creating a snapshot there could be a `vfsmonitor ${PREFIX}` which would record changes to a filesystem instead of creating a (potentially huge) snapshot. The idea is that packages with the same version do not always install the same files depending on which knobs are turned during configure, or equivalent. I want the information about the package installed on my system to accurately reflect what was installed, not what the person who generated a plist had insalled for them. I just had this happen with freebsd during installation of kerberos5. I didn't install kerberos4 compatibility, and hence the package would not be created because of missing files. I had to edit the plist because I turned some knobs in a makefile.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]