How are ports built now

[Matthew Seaman]

On 08/06/2014 17:54, Paul Schmehl wrote:
> It seems like a completely unworkable solution to me.  For example, say
> you have a port with 10 options.  Imagine how many different binaries
> you would have to have to cover every possible combination of selected
> options.  It would take a huge amount of storage

Yes.  You're absolutely right -- there is a combinatorial problem with
port options.  However there are three things that will help:

  * Sub packages.  Many option settings just add some extra files to a
    or data package.  With the plan to create sub packages -- ie.
    dividing up the files from a single software compilation into more
    than one binary package -- a significant proportion of that goes
    away.

  * The realization that we really don't need to build packages for all
    different possible combinations of options.  Some option sets
    simply don't work.  Others are for features that only a tiny
    minority of people would ever want.

  * The ports isn't going away.  If you need a special set of options
    for a particular port, then you will still have the choice of
    building from source via the ports.   Unlike many other packaging
    systems, the results of doing this will still be completely
    integrated with the packaging system, and you will be able to mix
    and match ports you compile yourself with binary packages from the
    repositories.

Hopefully the necessity of adopting the third option can be minimized,
although nothing is going to stop you doing that should you simply
prefer to do so.

Staging is one of the big pieces necessary to make this all work.  It
also has the interesting side effect that since everything is built as a
package it makes it quite natural to build your own package sets and set
up a package repository.

If you've got more than one FreeBSD system to manage[*], then I can
heartily recommend setting up a package building system and package
repository.  It's like night and day: you build off-line at your leisure
in a clean environment with no fuss and no worries if things don't work
entirely right first time -- you haven't affected anything of
consequence, so you can just fix the problem and try again without
downtime on important services.  You can install exactly the software
you'll be using on a test system and run it though all the QA you could
want before deploying it live.  The when it comes to doing the actually
installation of packages on your live systems it takes only seconds of
disruption, and you're done.  poudriere(8) + pkg(8) really is the
winning combination.

	Cheers,

	Matthew

[*] Or even if you only have just the one.


-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1036 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140608/12ddfa48/attachment.sig>