Bugzilla Bug 181063

it seem this version is in portage for over a half year.

And I searched the bug about this version, only this:
http://bugs.gentoo.org/show_bug.cgi?id=175423
which I never met in both amd64 and x86.

So I request to mark it stable.

Reproducible: Always

let's see if this isn't a real bug first, and after that, I'll be ok with
having it stable ;)

(In reply to comment #1)
> let's see if this isn't a real bug first, and after that, I'll be ok with
> having it stable ;)

That bug is fixed, so please stabilize 1.4.0a.

(In reply to comment #2)
> (In reply to comment #1)
> > let's see if this isn't a real bug first, and after that, I'll be ok with
> > having it stable ;)
> 
> That bug is fixed, so please stabilize 1.4.0a.
> 

+1

Hate to spoil it but this breaks ABI with the previous stable, thus requires a
revdep-rebuild and the ebuild doesn't mention a thing...
KDE bits are affected for example.

(In reply to comment #4)
> Hate to spoil it but this breaks ABI with the previous stable, thus requires a
> revdep-rebuild and the ebuild doesn't mention a thing...

I've rarely seen warnings about it and doubt this would make much difference,
but if you want I can add some ewarns; it cannot hurt.

> KDE bits are affected for example.

And a few others. One can survive if cinelerra fails to start, but people are
usually disapointed if their desktop manager fails to start... we can also
"group" it with a kde stabilisation so that it'll be less painful for kde
stable users. 

I usually don't bother with .so number changes when bumping, considering it is
necessary. Is there any policy that I'm not aware of about it ?

We've just finished stabilising KDE 3.5.7, I'm afraid. There's is probably
going to be a 3.5.8 but it's not yet on the horizon even.

I'm not aware of any policy about this either but, as you correctly pointed
out, users usually don't like their DE broken by a library update. :)

Thus, it's, IMHO, more a question of courtesy to users, especially since this
will break koffice, kdelibs, kdebase and others. The question to me is: Do the
benefits of stabilising openexr for our users now weigh heavier than the
inconvenience of having to recompile such heavy weights for them?

Please add krita (koffice) and imagemagick to the "at least" list.
If a user wants to know when his intervention is required (like with
PORT_LOGDIR in /etc/make.conf) some elog notice is required, otherwise it's
just a guess work.
I don't recall this being policy but i do know it's assumed behaviour when it
happens/is needed, otherwise you're just leaving people to guess things, create
unnecessary bugs and so on.

(In reply to comment #6)
> The question to me is: Do the
> benefits of stabilising openexr for our users now weigh heavier than the
> inconvenience of having to recompile such heavy weights for them?


I dont think so, there are no open bugs for either current stable nor 1.4.0a.
Let's just wait for another kde release, if kde/arch teams people think it's
wise.


(In reply to comment #7)
> If a user wants to know when his intervention is required (like with
> PORT_LOGDIR in /etc/make.conf) some elog notice is required, otherwise it's
> just a guess work.
> I don't recall this being policy but i do know it's assumed behaviour when it
> happens/is needed, otherwise you're just leaving people to guess things, create
> unnecessary bugs and so on.

imho it's more a problem of how we handle shared libs than some warning to make
the user notice it, but that's another debate.

I've just added some ewarn lines to 1.4.0a ebuild.

But "openexr" USE flag is not in any make.defaults and not everybody has
KOffice installed...

(In reply to comment #9)
> But "openexr" USE flag is not in any make.defaults and not everybody has
> KOffice installed...

Yes, but what would be the benefit of stabilising this now? Until this question
is answered, KDE would prefer to wait as we've broken enough user installations
with expat2/curl recently. :)

Without --as-needed hundreds of KDE packages are linked against libexpat.so,
while only the following KDE packages can use OpenEXR:

-------------------------------------------------------------------------------
                                     kdelibs
-------------------------------------------------------------------------------
 kdebase                                | kdebase-kioslaves
-------------------------------------------------------------------------------
 kdegraphics                            | kdegraphics-kfile-plugins
-------------------------------------------------------------------------------

Reemerging of 3 KDE packages isn't so hard.

(In reply to comment #10)
> what would be the benefit of stabilising this now?

Providing of the following:
 - Multithread support for reading and writing an OpenEXR file.
 - When compiling against OpenEXR headers, there's no longer any need to
   define any PLATFORM_* or HAVE_* macros; OpenEXR now supplies an
   OpenEXRConfig.h header file which is included by the OpenEXR headers that
   need these special macros.
 - New documentation for multithread support, plus some updates and additions.
 - Bug fixes releated to better handling of incomplete/damaged files.
 - Numerous bug fixes and cleanups to the autoconf-based build system.

stable on ppc

x86 stable

alpha/ia64 stable

Stable for HPPA.

Marked stable on amd64.

ppc64 stable

sparc stable

Closing wrt http://www.gentoo.org/news/20080210-mips-experimental-arch.xml