Checking port option descriptions

[Miroslav Lachman]

Matthew Seaman wrote on 09/19/2016 11:13:
> 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 agree that it can be useful for somebody but extremely? I don't think 
so and in case of pkg it is/can be opposite.

>> 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?

phpMyAdmin is slightly different beast which I abandoned long time ago - 
replaced by Adminer. And I personally don't know anybody using 
phpMyAdmin with full enabled options. And in a distant past phpMyAdmin 
has "WITHOUT WEB_DEPENDS" or something like this - which I used.

While we are talking about this sort of web applications there is my 
experience with Adminer from ports - it can provide support for MySQL, 
PostgreSQL, SQLite, MSSQL and ODBC.
It had no options in the past and even if you need it to access MySQL 
only it installs all the kind of useless dependencies.

In the end of this story - we are no longer using ports versions for any 
PHP web applications. We are using them directly because ports were more 
problematic.

> 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.

Yes, this is where new user are often lost - they don't know anything 
about why and how one checkbox can cause to compile tens of libraries 
making them wait half an our "just to install phpMyAdmin". But this is 
another story.

> 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.

pkg is too interactive anyway (compared to any older method) so I don't 
think this will be a problem. I think it will be useful to do this on 
install phase instead of package building phase.

>  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.

I think we can make some GUI distinction between options adding some new 
"compile time" functionality and "dependencies to simplify installation 
of many packages".
This can be the case for Amavisd-new. It has a lot of dependencies 
options but none or few of them are really required. As I said it can be 
useful but then it should be marked as something that just installs 
another package without modifying Amavisd functionality. You still need 
to configure Amavisd to use them or they are autodetected.
This is different for Postfix case where you must check MYSQL and 
compile it with MYSQL option to use it. You can't install MySQL client 
later and make Postfix work with it.

Miroslav Lachman