alternative options for ports

[Sebastian Schulze Struchtrup]

Eivind Eklund wrote:

>We should get a little more fine grained - NO_MENUCONFIG is the primary
>issue (as far as I can tell), while NO_OPTIONS suggest to me that we
>block all *reading* of options.  I personally would like (and probably
>use) a NO_MENUCONFIG for some kinds of builds, but I'd still want it to
>respect my stored options.
>  
>
Ok. That's reasonable. The names should be self-explaining.

>In the NO_MENUCONFIG case, we should probably also register user
>options, ie if a user type WITH_FLEXRSP=yes on the command line, it
>should be registered in the /var/db/ports/ configuration file.
>  
>
I am not sure if this would be good.
On the one hand, it is helpful when rebuilding a port. On the other hand 
it interferes with make.conf/pkgtools.conf.
Specifying an option there would lead to storing it in the options file. 
After removing it, it will still be in the options file.
This will probably generate some trouble and many headaches.

>As for the issues you brought up (I'd been planning to contact you about
>them anyway), the ones I've noted are:
>- Issues with release build - fixed by setting BATCH
>
>- Too many option popups - I think we could possible make
>  this a little better by batching all the option stuff
>  including what is necessary for dependencies up front,
>  so users can start a port, and when they see it going
>  forward, they know it will not block.
>  
>
This would be nice. Like config-dependent/recursive target.
It would be good to do this automatically when starting a port build.
This will work fine for building a singe port with its dependencies, but 
portupgrade probably needs to be modified for portupgrade --all. I am 
not sure about this yet.

>- Too many "small options" listed.  I believe we really
>  should list all options; if it is not important enough
>  to ask the users about, it isn't important enough to have
>  an option for at all.  Very very special case users can
>  compile from source or modify the port.  I've been trying
>  to think of some way to prioritize options etc, but nothing feels
>  at all right.
>  
>

>  I've been able to come up with one potential improvement for dependecy
>  controlling options: Having a global setting that specifies
>  "Minimal", "All", "Installed", or "Standard", which would make
>  all ports being installed auto-select what depenency set they
>  have when the set is optional (ie, configurable by WITHOUT_X11,
>  WITH_MAD_LIB, etc).  "Minimal" would minimize dependencies, "All"
>  would maximize dependencies, "Installed" would be minimal +
>  wahtever was already available, and "Standard" would be the
>  recommended set from the porter.
>  
>
Maybe this would be nice.
Especially "Installed", but in detail not trivial to implement.
For example, having an optional mysql dependency (regardliss if this 
would make sense or not) for a perl script.
Should a missing DBI/DBD::mysql be installed or not when only mysql is 
installed?
But for "Installed" there must be some standard way of specifying 
optional dependencies.
This should not be done on its own by every port maintainer. I will 
think about this.
Nevertheless, I am not sure yet about having this as an global option.

>- Generating packages with options.  This is presently done with slave
>  ports, which to me seems a stopgap solution, but one that mostly
>  solve our problems for the time being.
>  
>
>  Over time, I'd like to have some way to automatically generate
>  packages with some variations, ideally by listing some options
>  sets in the port, have the package building build all of them,
>  then find the differences between the installed sets and merge
>  those to a single package with all variants of the divergent
>  files included.  This would require that port builds for those
>  ports were reproducable, though.
>  
>
This is what I have thougt. Like OpenBSD's FLAVOURs (someone told me).
I would prefer this over slave ports, too, but some (or most) people 
don't like this.
Slave ports work and solve the problem. Thus it is ok. At least for now.



I have got another thought about options:
Currently, the port version is written into the options file, but it is 
not checked when reading options during a build. Right?
I think it would be good to automatically reconfig if the set of options 
has changed.
There are three ways to do this:

- always reconfigure when the port version changes. Not really nice, as 
options probably do not change very often. At least for minor updates.

- specifying an options_ver which will be bumped when an option is added 
or changed. I am not really happy with this.

- Building a hash (md5) over all given options and storing it in th 
options file. If the stored hash differs against the one calculated from 
the options given in them makefile, something has changed.

Just as an idea to think about.


Regards,
Sebastian