When this has come up in the past, I've had one (to me) CRITICAL concern.  
I don't remember ever voicing it before, so I'll do so, now.  Bear in mind
that this is speaking strictly as a user of pkgsrc.  (^&

Suppose that A has B as an optional dependancy, and that I have no
installed B.  Then, I install A, and everything goes well.  Later, I
decided that I really want B installed, so I install B.

GNOME, and I think KDE, both do some scanning of my system in order to
figure out what is installed.  So, if A is one of those two, I'm probably
alright in most cases.

Assume that A is not one of those two, and that it depends upon
compile-time decisions to know what it can expect about my system.  (E.g.,
Python using a threading library, say.)  Will building B then rebuild A
with the proper (optional, now-available) dependancy on B?

IMHO, it is unduly surprising to get two different versions of A depending
upon WHICH ORDER you build your packages in.

On the other hand, the back-and-forth checking of dependancies may be
prohibitive.


I wouldn't mind too much having the packages rebuilt, personally.  I would
be very disturbed, however, if the package that I got was dependant upon
the order in which I built my packages.

If a flag were used to convert optional dependancies, this might be
alright, though.  (I'd rather see a variable to turn optional dependancies
into hard dependancies, rather than ignored, though.  In general, packages
build without a hitch and those of us who always build from pkgsrc
probably won't mind the extra burden.  In turn, it makes the packages
``maximally functional'', and may help better test the package system.)

Another reason to prefer turning optional dependancies into hard
dependancies is that finding all of the optional pieces can be a
pain.


Just my 2.718281828459045 (and a fiddly-bit) cents' worth.  (^&


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu