Bug 171443 - Provides need to be inserted in spec file
Provides need to be inserted in spec file
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: imlib2 (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dams
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-21 14:17 EDT by Paul Johnson
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-24 21:16:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Johnson 2005-10-21 14:17:56 EDT
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:
Comment 1 Warren Togami 2005-10-23 12:41:38 EDT
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.
Comment 2 Rex Dieter 2005-10-23 13:19:04 EDT
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.
Comment 3 Ralf Corsepius 2005-10-23 13:29:54 EDT
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.
Comment 4 Rex Dieter 2005-10-23 13:35:13 EDT
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".
Comment 5 Michael Jennings (KainX) 2005-10-24 15:47:29 EDT
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?  :-)
Comment 6 Rex Dieter 2005-10-24 17:11:36 EDT
> 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
Comment 7 Ralf Corsepius 2005-10-24 18:26:14 EDT
(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.
Comment 8 Warren Togami 2005-10-24 21:16:18 EDT
> 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.
Comment 9 Rex Dieter 2005-10-25 10:17:00 EDT
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.
Comment 10 Ralf Corsepius 2005-10-25 10:37:42 EDT
(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.
Comment 11 Rex Dieter 2005-10-25 10:49:53 EDT
>> 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.
Comment 12 Ralf Corsepius 2005-10-25 11:18:05 EDT
(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
Comment 13 Rex Dieter 2005-10-25 11:24:01 EDT
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.
Comment 14 Michael Schwendt 2005-10-25 11:24:39 EDT
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.
Comment 15 Warren Togami 2005-10-25 11:26:34 EDT
A related question, why has nobody submitted eterm to Extras?
Comment 16 Michael Schwendt 2005-10-25 11:32:49 EDT
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
Comment 17 Ben Young 2005-11-18 04:01:50 EST
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!

Note You need to log in before you can comment on or make changes to this bug.