new package system proposal

[Matthew Seaman]

Polytropon wrote:
> Compiling applications in general will lead you into one
> main problem: Many ports have different options that need
> to be set at compile time. For a set of n options, 2^n
> packages would be created, if I consider the WITH_SOMETHING
> options only.

> One example is mplayer. Its various options select which
> codecs to include or if / if not to build with mencoder.
> In regards of different national law, it may even be
> prohibited to include a several codec, so it needs to
> be installed afterwards manually.
> 
> Another example is (you mentioned it) OpenOffice. In the
> past, I was happy to do
> 
> 	# pkg_add -r de-openoffice
> 
> or something similar. Today, I'm happy that someone put
> a precompiled package of OpenOffice online and announced
> it on the de- mailing list.

Hmmm... I was thinking about this the other day.  There are two
classes of behaviour where OPTIONS functionality could be passed
down to the compiled pkg level.

The first is where choosing an option /only/ affects the dependency
tree for a package.  The phpMyAdmin port I maintain is like this:
by setting OPTIONS you can avoid installing some php modules -- the
phpMyAdmin code automatically detects the presence or absence of
those modules and does the right thing automatically.  Adding an
interactive options menu to provide the same functionality when
installing from packages seems to me to be do-able, although I admit
to no great expertise at C programming.  However, aside from meta-
ports, this sort of OPTIONS behaviour is probably fairly unusual in
the ports tree.

The second case is far more common and far more interesting.  This is
where toggling an option controls whether some sub-set of files get
installed or not, without any changes to other parts of the port.
Adding different localizations in many programs, or choosing which
out of a set of drivers for different pieces of hardware to install
(eg. in print/ghostscript8) are cases in point.  Now, one answer to
providing the full flexibility of such a port when installed via
packages is simply to split up the port into a lot of smaller ports,
which reduces the problem to the previous one of using OPTIONS to 
control the dependency tree.  The various different php5 modules are
a good example of this sort of approach in practice.  The disadvantages
are exploding the number of directories within the ports tree, requiring
maintainers for all of the newly created tiny little ports and generally
increasing the amount of work it takes to maintain everything.

Now, one way of alleviating some of the the maintenance burden would be
a fairly simple idea I had.  At the moment, there's a one-to-one
relationship between port directories in the ports tree and the packages
installed from them.  But that doesn't have to be so:  why can't typing
'make install' in a port directory end up installing several different
packages?  Seems quite feasible to me to install a number of sub-ports
as one operation.

One final note: there's a degenerate case of this behaviour for virtually
all ports in the tree.  When installing from ports, you can set
'NOPORTDOCS' and 'NOPORTEXAMPLES' to avoid installing documentation or
examples respectively. When installing from packages you don't get that
capability.  Having foo-docs-n.nn.nn and foo-examples-n.nn.nn sub-ports
would give you that.

	cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090404/86b47522/signature.pgp