Port WITH_* options and updates/portupgrade

[Matthias Andree]

Oliver Braun <obraun at unsane.org> writes:

> Take a look at the MAKE_ARGS hash in $PREFIX/etc/pkgtools.conf.
>
> You can use things like
>
>     MAKE_ARGS['mail/postfix']='BATCH=yes POSTFIX_OPTIONS=\"SASL2\"'
>
> there.

Michael Edenfield <kutulu at kutulu.org> writes:

> Anything that you can pass on the make command line you can put into 
> /usr/local/etc/pkgtools.conf.  This is what I have for postfix to 
> always build with DB3:
>
>   MAKE_ARGS = {
>     'mail/postfix' => 'BATCH=1 POSTFIX_OPTIONS=DB3',
>   }

[...]

> The downside is that you need to remember to always use the pkgtools 
> like portupgrade.  It's also easy to forget to add new ports when you 
> need them, but eventually it becomes second nature.

And that's exactly the problem: the "solution" is local to the tool,
rather than global for the ports system.

I have no implementation ideas yet, but let's assume the system is
called "portsconfig". The functionality I'd like to see is:

a. in batch mode, portsconfig will retrieve the "last time" settings
    and, lacking these, resort to the port's defaults; regardless of the
    way the port is built (manually vs. via portupgrade).

b. in interactive (non-batch mode), portsconfig will take care of the
   dialogue.

c. The port just passes in tuples (description, option) and its own name
   and portsconfig takes care of presenting the dialog or retrieving the
   data.

d. data is persistent until deleted (so each option will also have an
   option to counter it, so that the system remembers WITHOUT_TDB so I
   can get rid of an earlier WITH_TDB.) /var/db/pkgoptions?

e. information is recorded in packages built so that portupgrade on a
   port that was installed by pkg_add -r gets the same options, without
   the user editing pkgtools.conf or looking up anything. (+OPTIONS
   file?)

I wonder if there's much to it implementation-wise. Essentially, ports
would have to standardize how they query, store, retrieve their A4=yes,
SASL2, WITH_TDB, options, and if it saves some work, port maintainers
will go for it. The user will also profit from a more consistent ports
configuration.

Listing the port configuration variables in another variable, or
automatically extracting them if they have a standardized name format,
might work. make -V will be one of our friends.

-- 
Matthias Andree