| Summary: | request to stabilize media-libs/openexr-1.4.0a | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Steve Yin <steve> |
| Component: | New packages | Assignee: | MIPS Porters <mips> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | media-video, radek |
| Priority: | High | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 175423 | ||
| Bug Blocks: | 146062 | ||
|
Description
Steve Yin
2007-06-06 10:33:36 UTC
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 |
