[csw-maintainers] A policy issue

[Roger Håkansson]

What is the policy regarding removing (i.e not configuring optional 
functionality before build) functionality when releasing a new version 
of a package?
And also, what are the policy on backporting Solaris8/9-support which 
have been removed by upstream vendor?

The reason for asking is this:

The current imagemagick-package have support for openexr image format 
which in CSW lies in the package openexr.
When I started my journey to updating imagemagick, I discovered some 
depending packages which like imagemagick had an non-active maintainer 
and which was in need of updating, so I took upon myself to update some 
of those packages too.
But then i discovered that not only have openexr been split into two 
separate download packages (ilmbase and openexr, which is no big 
problem, I can create a new package and make openexr dependant on that 
one), but also they have removed a bit of code in ilmbase (actually they 
did it already in openexr-1.4, where the current is 1.6 and CSW-current 
is 1.2) which makes it impossible to compile on Solaris 8 and Solaris 9, 
due to nonexistant floating point arithmetic funktions (sinf,cosf...).

As I see it, the possible solutions are:

- Keep compiling imagemagick against current CSWopenexr, with the 
possible implication that we might have to drop openexr-support in the 
future when imagemagick requires an newer openexr-version
- Drop openexr-support in CSWimagemagick
- Backport the old code which upstream removed, as a "CSW-patch" with 
the implication that it might have some impact on 
openexr-stability/functionality (in this case, the "backport" consists 
of an ifdef/else with two different C++-templates, where one uses 
asin/cos/sin and the other asinf/cosf/sinf, so it should work, but we 
never know what the ILM-guys might do in the future).


The question is which solution is the preferred one?