HEADS UP: New bsd.*.mk changes

Oliver Eikemeier eikemeier at fillmore-labs.com
Tue Jan 20 07:16:08 PST 2004


Marius Strobl wrote:

> On Tue, Jan 20, 2004 at 06:09:42AM -0800, Eivind Eklund wrote:
> 
>>On Tue, Jan 20, 2004 at 02:59:39PM +0100, Oliver Eikemeier wrote:
>>
>>>Eivind Eklund wrote:
>>>
>>>>improvement).  And I thought it was supposed to be unique, while it seems 
>>>>it isn't.  That said, I think the name LATEST_LINK should be changed 
>>>>(possibly
>>>>not right now) if LATEST_LINK is to be used this way. 
>>>>
>>>>Also, I don't see why LATEST_LINK would always be unique - instead, it 
>>>>looks to
>>>>me as if there could be conflicts between different ports on this (while I 
>>>>thought
>>>>we defined that there shouldn't be for PORTNAME).
>>>
>>>The problem with the current solution is that renaming OPTIONSFILE is not
>>>easy, because ${PORT_DBDIR}/${PORTNAME} is somewhat hardcoded in bsd.port.mk
>>>now. I can change PORT_DBDIR, but have to accept ${PORT_DBDIR}/${PORTNAME},
>>>which is bad. Perhaps we should have
>>>OPTIONSFILE?=${PORT_DBDIR}/${LATEST_LINK}.options,
>>>which is easier to change.
>>
>>I don't think this particular name is usable right now - we "need" something
>>that falls back to ${PORT_DBDIR}/${PORTNAME}, as the OPTIONS system is now
>>in production, ports have started to use it[1], and people will have started
>>storing options in just a few hours.  Unless we can resolve this within
>>those few hours, we need to have the same ultimate fallback.
>>
>>[1] Well, only security/snort so far, so I'm going to ask the committer to
>>    back that out until the present hoopla is sorted out.
>>
>>>LATEST_LINK should be unique for each package, and I guess if two ports 
>>>have the same LATEST_LINK they CONFLICT anyway.
>>
>>Whether they conflict is really immaterial - they shouldn't share options.
>>
>>>But I don't care if we use LATEST_LINK or something else, as long as it
>>>is easily changeable in the case of conflicts.
>>
>>PORTNAME?  ;-)
> 
> Neither seems appropriate for the default. PORTNAME is not unique among
> ports which are only distinguished by their PKGNAMESUFFIX, for example
> security/openssh-portable and security/openssh or pretty much any port
> where a corresponding "-devel" port exists. Such ports might or might
> not share the same set of options with their siblings which share the
> same PORTNAME, but at least since CONFLICTS now takes PREFIX into account
> they could be installed with different options into different PREFIXes
> without conflicting further.
> LATEST_LINK on the other hand per default includes PKGNAMESUFFIX so one
> would end up with different OPTIONSFILEs for ports which add PKGNAMESUFFIX
> based on optional features, think of all the ports that optionally can
> be built with support for GNOME and then define "-gnome" as PKGNAMESUFFIX,
> so OPTIONSFILE wouldn't be unique per port and defeat its purpose.
A lot of ports use -client and -server as a PKGNAMESUFFIX, so it is not
clear if it should be considered or not.

> I'm not sure what a sane default for OPTIONSFILE would but but it at
> least has to be easily overridable which currently isn't given.
Yep.



More information about the freebsd-ports mailing list