From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: The Enlightenment team, which develops Imlib2, offers RPMs that are packaged into smaller pieces. Packages built on the Enlightenmnet IMlib2 packages will not install against your package because those other programs look for imlib2_jpegloader and such like that. A forced install of the Eterm rpm will, for example, will lead to a working Eterm, but there's a better fix. In your spec file, please insert Provides: imlib2-loader_jpeg, imlib2-loader_png Version-Release number of selected component (if applicable): imlib2-1.2.1-1.fc4 How reproducible: Always Steps to Reproduce: 1. Install imlib2 from Fedora Extras 2. Try to install Eterm-0.9.3 from www.eterm.org 3. Actual Results: Install is refused because missing rpms imlib2-loader_jpeg and imlib2-loader_png Expected Results: Eterm needs to be told you include those features in your RPM Additional info:
Potentially the upstream Eterm RPM is wrong in artificial dependencies of these package names when RPM autoreq resolution should be fine. There is also little reason why Fedora should support the whims of an arbitrary external RPM, especially when that RPM can be included in Extras itself. I am tempted to say NOTABUG, but let's see what fedora-extras-list says first.
In this case, 1. I don't think RPM autoreq resolution would pick it up. 2. The "whims of an arbitrary RPM" here is the upstream source, hmm.. at least I thought so, but I can't seem to find any imlib2 rpms at http://www.enlightenment.org/ If the source of these imlib2 rpms that eterm is built against isn't authoritative (ie, more authoritative than Fedora Extras' imlib2), then I'd have to agree NOTABUG, and that www.eterm.org is providing bad rpms.
The essential point would be: Which files is eterm wanting to load dynamically? An eterm package should requires these, and if this affects imlib2, imlib2 should provide these files.
It looks like eterm wants: /usr/lib/imlib2/loaders/jpeg.so /usr/lib/imlib2/loaders/png.so (which imlib2 already Provides). These are what eterm should "Require".
Warren: No, the upstream RPM is not "wrong." RPM autoreq resolution will not pick up the required loaders because they are dynamically loaded at runtime when trying to load a JPEG or PNG image. The default theme uses both these formats and thus requires those two loaders be present. Rex: Authoritative upstream packages for Imlib2 can be found at http://enlightenment.freedesktop.org/ (tarballs containing spec files) and http://mirror.caosity.org/cAos-2/ext/autobuilder/i386/00_LOGS/e/imlib2/ (source and binary RPM's). Your suggestion to require the specific .so files is incorrect: it fails to account for multi-arch and /usr/lib64. The sad part of all this is that it would've taken far less time to simply add the Provides: lines suggested to the spec file than to carry on this discussion. You even had them provided for you to cut-and-paste! So why not do that instead of playing the Fedora-is-right-and-everyone-else-is-wrong game? :-)
> Your suggestion to require the specific .so files is > incorrect: it fails to account for multi-arch and /usr/lib64. Not if you use: Requires: %{_libdir}/imlib2/loaders/jpeg.so Requires: %{_libdir}/imlib2/loaders/png.so :-) Regardless, unless there is some good argument against it (which I don't see), FE should follow upstream -> REOPENING
(In reply to comment #6) > Regardless, unless there is some good argument against it (which I don't see), > FE should follow upstream -> REOPENING Do I really have to mention the obvious? To stay polite, in this case, upstream is trying to impose artificial contraints and is trying to force their proprietary conventions to FE's packaging. As the eterm mentioned above is not an FE package, their packaging, their conventions etc. are irrelevant.
> To stay polite, in this case, upstream is trying to impose artificial contraints > and is trying to force their proprietary conventions to FE's packaging. > As the eterm mentioned above is not an FE package, their packaging, their > conventions etc. are irrelevant. I totally agree with this. Upstream's RPM is imposing artificial requirements. Use the Requires syntax from Comment #6 and everyone will be happy. Closing NOTABUG because this is not a Fedora Extras package problem.
IMO, upstream is not being proprietary or imposing anything. And, no, the "artificial constrains/requirements" argument doesn't fly. Looking at the upstream imlib2 specfile shows they simply chose to package each plugin separately (a valid, but way-overboard packaging choice). Now, I can understand FE not following suit there. What I don't understand is why anyone would advocate FE purposely breaking compatibility with upstream packaging in this regard (by not using Obsoletes/Provides), without a good argument to do so. Heck, it's only a few lines added to the specfile.
(In reply to comment #9) > upstream is not being proprietary or imposing anything. Am I blind? In comment #1 you can read: > In your spec file, please insert > > Provides: imlib2-loader_jpeg, imlib2-loader_png I.e. they want us to add artificial "provides", without any technical need to do so. > And, no, the > "artificial constrains/requirements" argument doesn't fly. Cf. above. It's what they are doing. They tell Fedora, "Wear this batch or die". > Looking at the > upstream imlib2 specfile shows they simply chose to package each plugin > separately (a valid, but way-overboard packaging choice). Where's the problem? It's a reasonable design. > Now, I can understand FE not following suit there. What I don't understand is > why anyone would advocate FE purposely breaking compatibility with upstream > packaging in this regard (by not using Obsoletes/Provides), without a good > argument to do so. > Heck, it's only a few lines added to the specfile. Heck, apparently you force me to become direct: These guys chose a broken approach: Instead of forcing others to do what they want, they should use those requirements they actually use, not those they want to impose on others: If eterm loads (probably dlopens) /usr/lib/imlib2/loaders/jpeg.so then they probably should Require this inside of their rpm. This file already is provided by the imlib2-rpm. If eterm loads jpeg.so from some path, they can "Require: jpeg.so". This virtual property already is provided by the imlib2-rpm.
>> package plugins separately separately >> (a valid, but way-overboard packaging choice). > Where's the problem? It's a reasonable design. Gotcha. You admit upstream packaging is reasonable, but without Obsoletes/Provides, FE's packaging is certainly not compatible or upgradable back-n-forth. > These guys chose a broken approach: Instead of forcing others to do what they > want, they should use those requirements they actually use, not those they > want to impose on others: However, I (and probably many outside of Fedora) will see this the other way around: that Fedora has a NIH problem, and is trying to "impose" its Requirements on others by refusing to be compatible with upstream. FYI, Requires: jpeg.so doesn't work on x86_64.
(In reply to comment #11) > >> package plugins separately separately > >> (a valid, but way-overboard packaging choice). > > > Where's the problem? It's a reasonable design. > > Gotcha. You admit upstream packaging is reasonable, but without > Obsoletes/Provides, FE's packaging is certainly not compatible or upgradable > back-n-forth. BS - Spliting a package an application uses into subpackages has nothing to do with the topic we are discussing. A split out package must provide the same internal symbols as a non-split package. As applications can not expect all vendors to adopt their packaging, using package-name in 3rd party application rpm.specs is non-portable. They have manoeuvred them into a dead-end! > FYI, Requires: jpeg.so doesn't work on x86_64. And you know how to work around it! However, if their application is supposed to work reliable, they probably are using hard-coded paths ;) Ralf
To sum up: My (and Paul's) opinion is: Fedora should/try-to be compatible with upstream packaging, unless there is a compelling argument otherwise. Ralf's/Warrent's opinion: If FE packaging varies from upstream (compatibility-wise), there should be a compelling argument to modify FE packaging to match/be compatible with upstream. If this is accurate, and no-one changes their mind, I think at this point, we can agree to disagree.
Unconvincing. > Provides: imlib2-loader_jpeg, imlib2-loader_png The fundamental problem here simply is, Fedora Extras has packaging guidelines for the sake of avoiding packaging pitfalls and problems. Explicit and hardcoded dependencies on non-versioned package names are bad. They ought to be avoided, particularly since imlib2-loader_foo packages or virtual Provides don't exist within Fedora Extras. Adding them would create virtual dependencies on something which isn't tracked anywhere. There is absolutely no point in taking over a broken package design just to follow upstream's packages. Many upstream projects distribute first-come-first-served contributed packages which are packaged poorly or which change rather wildly as contributors send in spec changes. The notion of "authoritative upstream packages" is over the top, IMO. The Eterm package even adds "Requires: imlib2", which would dictate using "imlib2" as the package name, which is inacceptable in times of automatic SONAME dependencies. The src.rpm contains only an old spec %changelog dating back as far as Red Hat Linux in 2001 without mentioning any changes since then. Comparing with SuSE Linux 9.3: $ rpm -qp --provides imlib2-loaders-1.1.1-7.i586.rpm argb.so bmp.so bz2.so gif.so jpeg.so png.so pnm.so tga.so tiff.so xpm.so zlib.so imlib2-loaders = 1.1.1-7 Cannot see the Provides in a Mandrake Cooker rpm either.
A related question, why has nobody submitted eterm to Extras?
Interestingly, SuSE 9.3 has them in the main library package with the loaders in the sub-package "imlib2-loaders". That won't work either. $ rpm -qp --provides imlib2-1.1.1-7.i586.rpm imlib2-loader_jpeg imlib2-loader_png imlib2-loader_argb imlib2-loader_tiff imlib2-loader_gif imlib2-loader_zlib imlib2-loader_bz2 imlib2-loader_pnm imlib2-loader_bmp imlib2-loader_xpm imlib2-loader_tga libImlib2.so.1 imlib2 = 1.1.1-7
Michael Jennings is forcing Fedora to repackage imlib2 to get the loaders in separate packages. M. Schwendt way of packaging imlib2 is correct. Now the way to solve it is simple: Just alter the new Eterm's spec file as follows: BuildRequires: libast, imlib2-devel, xorg-x11-devel and don't include the imlib2-loader_foo whatever. This has been correctly done by Didier Casse in his repo located at: http://sps.nus.edu.sg/~didierbe/ He's distributing Eterm-0.9.4cvs. Don't bother about Eterm 0.9.3. It's an old version of Eterm and is unmaintained by Mej. Just trash it!