HEADS UP: New bsd.*.mk changes

Marius Strobl marius at alchemy.franken.de
Tue Jan 20 07:02:18 PST 2004


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

Another thing that bugs me is that a port using OPTIONS can no longer be
built as non-root. Could the creation of PORT_DBDIR and the OPTIONSFILEs
be delayed until the install stage?



More information about the freebsd-ports mailing list