Matthew Seaman wrote:
You've suggested solutions to a couple of Polytropon's objections, thank
you. Do you think there is anough mileage in my suggestion to make it
worth putting in front of some ports people? What would have
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
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.
to happen to take it forward? I could rewrite the proposal more clearly.
I suspect it would be easier to implement than freebsd-update, as a good
deal of the infrastructure already exists, and would have similar
benefits. To start developing it would require a ports tree and a
selection of packages compiled from that ports tree. 7.2 Release is
coming up. Maybe the ports tree plus packages from that would be a good
place to start.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"