Base packaging

Paul Richards paul at
Fri Sep 19 03:22:48 PDT 2003

On Fri, 2003-09-19 at 02:10, M. Warner Losh wrote:
> P.S.  How do you handle the packlist generation?  The ports system
> doesn't automatically generate these things, as far as I can tell, and
> I didn't see anything that you've added to do this.
> My agenda, if you will, on this is to deal with:
>    upgrades: portupgrade can grok packages.  If you had a good way to
>    generate the package list, then we could make it a lot easier to do
>    binary upgrades.  Thie would let me have a big meta-port that
>    covers all the 'standard' things on the machine, including the os.
>    Chances are good that some care would need to be taken in
>    portupgrade to make sure that it doesn't use binaries in place that
>    will be replaced.

It should be able to do this. Anything you can do with ports I hope
you'll be able to do in the standard tree, i.e. have dependencies and
meta ports etc.

>    subsetting: with the proper set of subsetting, one could easily
>    create packages such that they could install just what they
>    needed.  It might be good to have a few like "minimal to boot with
>    rc.d" and the like.

This will probably work already. There's no real magic to what I did,
you can convert any makefile to understand ports just by adding PORTNAME
to it, but it doesn't hook into all the ports targets, just fake-pkg. So
basically if you do make install with one of these modified Makefiles
then it will register a package based on the pkg-plist in that
directory. That plist could contain anything you want.

So, you can create a Makefile in the main tree to build a package with
any files you want, you just have to craft the plist e.g. you could have
/usr/src/dists/{minimal,full, sources} etc and in each dir you'd have a
skelton port, with a Makefile, pkg-descr, pkg-plist etc. The pkg-plist
would determine the list of files in each dist. You could of course
break this down to be much more fine grained in the makefiles that
actually build the code to create lots of small packages and then have a
meta package at the dist level to pull them all together.

>    nopriv: it should be possible to build a release w/o any privs at
>    all.  NetBSD does this with hacks to install and pax to journal
>    installation stuff in a certain mode and a new mkfs program to take
>    that info and create a file system image that can be used in the
>    target environment.

I haven't done any work on this, but it's on my todo list for different
reasons. I'd like to be able to run a dummy install to generate a plist
i.e., if I wanted to package sbin then in /usr/src/sbin I could run make
plist to create the pkg-plist for me based on everything under
/usr/src/sbin, just to save the effort of it being done manually.

To achieve that I'll do something similar to NetBSD and have an option
to install that registers the installation in a file rather than
actually doing it, so you could run this dummyinstall step and then make
package and you'll end up with a load of package files that can be
installed later as root.


More information about the freebsd-ports mailing list