HEADS UP: [msg #2] graphics/ilmbase and graphics/OpenEXR update planned includes openexr rename - feedback required until Sept 23/portmgr Sept 21

[Matthias Andree]

Am 17.09.18 um 18:39 schrieb Tobias C. Berner:
> Moin moin
> 
> Do you have a list of the kde@ ports broken by the update? Or is this a
> compile everything, then fix it call? 

Moin Tobias,

Thanks for picking up the thread for kde at .

This list you are asking about is empty, but you never know what happens
with sweeping changes in the field after the fact, that's why I am
pushing forward. We don't want a high-profile port diverging between
quarterly and head, and we don't want to duplicate fix efforts right
after the branch.

I have compile-tested all ports in poudriere 11.2-RELEASE amd64 that
have a direct dependency on ilmbase or OpenEXR listed that is either
mandatory, or an option that defaults to "ON".

The only casualty is the unmaintained (upstream and ports)
graphics/ampasCTL (see below why) and none of the *kde* or *qt* ports
have broken or killed ports that require them.  I may take one or two
more stabs at ampasCTL to see if it turns out to be low-hanging fruit.


My call is "check if you have any concerns about my proposed update to
ilmbase/OpenEXR and the OpenEXR -> openexr rename".
The proposed update is the one I provide as patch, not the earlier shar
file.

If you are keeping an outside private KDE repository, you may have to
merge my patch into your private kde@ repository once I commit, and test
your own ports that depend on ilmbase/openexr before you commit your
tree back to the FreeBSD ports repository.


NOTE:  I think I do not formally need to ask approval about PORTREVISION
bumps and bumps to requisite library changes, we do not normally do that.

I do want to coordinate nonetheless, and I'll happily receive approvals.

I just can't afford to spend hours on end to chase down everybody behind
mail exploders.  I believe I've done a thorough job of testing the
builds and direct dependents, and if someone wants to do a full -exp
run, use the patch from my previous message, URIs repeated below for
convenience:

- https://people.freebsd.org/~mandree/openexr-v2.patch
- https://people.freebsd.org/~mandree/openexr-v2.patch.asc (GnuPG sign.)


Note that OpenEXR is not formally advertised as incompatible, what I
found out so far is:

* "Iex::BaseExc no longer derived from std::string." is what appears to
have broken ampasCTL
<https://github.com/openexr/openexr/releases/tag/v2.3.0> because it
can't seem to std::cout << ... those data types any more and I get a
truckload of excuses why none of the candidates is viable for automatic
type conversion.  Haven't yet dug deeper, but I don't consider an
unmaintained (upstream & downstream) leaf port as sitting in the
critical path anyways, we can fix it after the fact (and the fix could
also be MFHd from head to quarterly without ado since it's unbreaking a
broken port, hence pre-approved).

Cheers,
Matthias