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):
Steps to Reproduce:
1. Install imlib2 from Fedora Extras
2. Try to install Eterm-0.9.3 from www.eterm.org
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
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
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:
(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
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:
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.
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
> 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
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 ;)
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.
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.
> 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
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
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
$ rpm -qp --provides imlib2-1.1.1-7.i586.rpm
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:
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!