Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Jan 2004 16:14:12 +0100
From:      Oliver Eikemeier <eikemeier@fillmore-labs.com>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        Kris Kennaway <kris@obsecurity.org>
Subject:   Re: HEADS UP: New bsd.*.mk changes
Message-ID:  <400D45C4.6040707@fillmore-labs.com>
In-Reply-To: <20040120160137.A10434@newtrinity.zeist.de>
References:  <1074590694.85583.20.camel@shumai.marcuscom.com> <400D2939.5090203@fillmore-labs.com> <20040120133020.GB94636@FreeBSD.org> <400D344B.6010403@fillmore-labs.com> <20040120140942.GD94636@FreeBSD.org> <20040120160137.A10434@newtrinity.zeist.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?400D45C4.6040707>