On 09/19/16 08:48, Miroslav Lachman wrote: > The next problem is options doing nothing to "this" port but just pull > some other port as dependency because maintainer thinks it is useful for > the end users to have installed it too - this should be avoided (IMHO).
I must respectfully disagree here. Options that only affect the
run-time dependencies of a package are extremely useful.
> I don't have port names in hand but I know I saw this in the past.
Well, how about phpmyadmin as a for-instance? There are about eight PHP
modules which phpmyadmin will automagically adapt to the presence or
absence of at runtime and turn on or off corresponding bits of its user
interface. So, for example, if you have pecl-pdflib installed it will
give you options to generate a PDF diagram of your database schema.
These are all options in the port, and they are on by default, because
why wouldn't you want the full functionality of phpmyadmin enabled?
Well, rhetoric aside, some of those options do pull in some quite big
dependency trees. So, for instance, you can avoid pulling in all the
X11 client libraries by turning off the GD option -- of course, this
does lose you support for generating some diagrams.
I do agree though that options of this type are conceptually different
to most other cases. For example, in principle there's nothing to
prevent pkg(8) throwing up a dialogue at install time and asking you
which of those run-time dependencies you want installed. Now, that
hasn't been implemented because there are questions about forcing pkg(8)
to be too interactive, which would be problematic, plus we'd need to
have a mechanism in the ports to mark these sorts of dependencies.
From pkg(8)'s point of view, this would behave very similarly to some of
the ideas around 'sub packages' -- i.e.. having a separate packages of,
say, debug symbols or docs or examples that you could choose to install
at runtime or not.
Cheers,
Matthew
signature.asc
Description: OpenPGP digital signature
