OPTIONSFILE path [HEADS UP: New bsd.*.mk changes]

[Oliver Eikemeier]

Joe Marcus Clarke wrote:

> On Wed, 2004-01-21 at 11:33, Oliver Eikemeier wrote:
> 
> [I think we're all on the same page at this point.]

Maybe I have to restate that I'm extremely happy that we finally have
started ports option handling. 

>>I admit that I'm not very happy with what seems to be making a mountain out of
>>a molehill, but OPTIONSFILE still doesn't work the way we want it to:
> 
> Agreed, but we went with an option that didn't have the potential of
> breaking any existing bsd.port.mk functions.

Yes, all those last minute changes are very unfortunate, I sorry about that.

>>- We need OPTIONSFILE in bsd.port.pre.mk to check for existing options.
>>- WITH_*/WITHOUT_* options are available *after* bsd.port.pre.mk
> 
> Right.  That's noted in the OPTIONS comment at the top of bsd.port.mk.

I'm just listing the facts for an easy reference.

>>- Some ports set their PKGNAMESUFFIX depending on the options,
>>  like -apache2 in www/mod_jk, or -nox11
>>- Some ports need a different set of options depending on PKGNAMESUFFIX,
>>  like -client and -server
> 
> True.  However, I would argue that in some of those cases, those options
> should not be exposed to the end user since there are usually slave
> ports set up that set those options (e.g. Mozilla, MySQL, OpenLDAP,
> etc.).  I would never add WITH_GTK2 to Mozilla's OPTIONS since users
> should be using mozilla[-devel]-gtk2 instead.

No, I wanted to show that we have contradicting premises:

a.) the PKGNAMESUFFIX may be dependend on user settable options

b.) the set of saved options to choose may be dependant on the PKGNAMESUFFIX
    (even though it might not be determined by user settable options)

This means that in case a) we can't use the PKGNAMESUFFIX to determine the
set of saved options, and if we can't do this we have to work around this
for case b.), e.g. set LATEST_LINK or UNIQUENAME for *every* port that
has options depending on the PKGNAMESUFFIX.

This is more dangerous as it seems: If one port doesn't use OPTIONS and has
a portname of apache, it will nevertheless get the options from
/var/db/ports/apache/options.

Say for example you do a test installation of apache2 (which we assume support
OPTIONS) and decide to downgrade to apache13 (which we assume doesn't support
OPTIONS), then the file /var/db/ports/apache/options is sourced nevertheless,
and you get all saved options from apache2 for apache13. There is no 'Hey, I'm
OPTIONS-aware and want saved options, and I am willing to care for a unique name',
you get the options when a 'suitable' file is found.

Did you expect that?

>> [...]
>>- eliminate some verbatim uses of dirname, rm and id
> 
> Please pull these diffs out.  We don't want to cloud this diff with
> extraneous stuff.  Thanks.
Okay, will do.

>>Sorry for making all the fuss about the OPTIONS macro, but I think it's *bad*
>>if somehow ports get compiled with unexpected options, and currently that is
>>more than likely.
> 
> Well, technically, nothing is very likely now since I know of only two
> ports that are using the new OPTIONS framework (maybe only
> games/moonlander now).  And remember, porters can override all aspects
> of the OPTIONSFILE name at this point, so problem ports can be worked
> around.

If you find or expect them. See my example above. But I can add OPTIONSFILE and
PKGLATESTFILE to CONFLICTS checking ;-)