[csw-maintainers] A policy issue

[Dagobert Michelsen]

Hi Roger,

Am 18.02.2009 um 16:35 schrieb 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...).

Basically it is expected from the package maintainer to fix issues
with older Solaris releases. But if the Solaris version was
deliberately desupported upstream this goes IMHO too far to work
against upstream policy.

> 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

Current means 1.2 and that means very old here. Not good.

> - Drop openexr-support in CSWimagemagick

Not good, as the policy is also to build with full dependencies.

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

This would be asking too much from the package maintainer IMHO.

There are two more options:

- Build openexr only for Solaris 10, build separate packages for
Solaris 8+9 and 10, where only the Solaris 10 version depends on
openexr.

This would go against the policy of providing libs for all Solaris
releases. Users on Solaris 8 and 9 using openexr right now would be
left without a package.

- Build openexr 1.4 (the last version supported for Solaris 8 and 9)

This would go with all policies at OpenCSW without discussion.
Solaris 10 users wouldn't get what they can get.

- Build openexr 1.4 on Solaris 8+9 and openexr 1.6 on Solaris 10

This would lead to a situation with diverging library versions
between the Solaris releases, but would bring the best to all
platforms available. I guess I prefer this solution.

Other opinions on this topic?


Best regards

   -- Dago