Xml in packaging system

[Craig Dooley]

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
./configure --prefix=/usr/local
make install DESTDIR=/pkgbuild

and programs that dont support these directives.  
Thats was my idea of how things would be done.  Like gentoo sandboxing, but 
much better.

-Craig

On Friday 31 October 2003 14:32, Galen Sampson wrote:
> 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
> >     ok
> >     % vfsmap libexpat		(map in the highest installed version)
> >     ok
> >     % vfsmap libc
> >     ok
> >     % 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.
>
> regards,
> Galen

-- 
Craig Dooley											cd5697 at xxxxxxxxxx
Attachment:
pgp00007.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 187 bytes
Desc: "Description: signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20031031/188c2e0c/attachment-0020.obj>