RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc.

Mike A. Harris mharris at redhat.com
Tue Feb 3 07:09:27 UTC 2004


On Mon, 2 Feb 2004, Sam Varshavchik wrote:

>> All rpm packages containing applications/libs which link to the
>> standard X11 libraries, currently have hard coded dependancies 
>> such as:
>> 
>> Requires: XFree86-libs
>> Buildrequires: XFree86-devel
>
>At least the first part should not be necessary.
>
>find-requires.pl will automatically add dependencies on every shared library 
>loaded by any binary in the package.  pan, for example, automatically gets a 
>dependency on libgdk-x11-2.0.so.0, by the virtue of linking with it.

Correct, but I don't want to assume that there are no packages
out there that don't explicitly list that.  Or for
non-native-English readers, to eliminate the triple negative I
just used without thinking...  I want to assume that there are 
packages out there that do list that.


>This dependency is provided by the gtk2 RPM which, in turn,
>automatically has a dependency on libX11.so.6, libXext.so.6, and
>others, by the virtue of linking against those libraries.  This
>is sufficient to require XFree86-libs.

Sure...

>I don't think you need anything special to correctly resolve
>runtime dependency of X applications.  If you use a substitute
>X11 server+libraries, as long as the substitute installs
>libX11.so.6, et al, everything will work correctly.

The problem being solved is if something already _does_ require 
that package.  I would not be willing to state "zero rpm packages 
in the distribution, and zero rpm packages outside of the 
distribution have a hard coded dependancy on XFree86-libs".  In 
fact it's possible some package might have:

Requires: XFree86-libs >= 4.3.0

in order to meet some bugfix dependancy that occured over time or 
something.  In short, I assume nothing, plan for the worst and 
hope for the best.

>find-provides.pl automatically declares a provides for all matching shared 
>libraries installed by the package, so you do not need to do anything 
>explicit with the substitute X11 servers/runtime libraries.  As long as they 
>install shared libraries that have the same names (even if they are 
>installed in different directories!), all runtime dependencies will be 
>satisfied.

But find-provides can only handle automatic dependancies on a 
library or whatnot, it can't know things like "that version of 
the library was broken, force the requirement of a newer 
version".


>As far as development libraries go, it does look like an
>explicit Requires:  may be necessary.

Yep.

>You might be able to get away with adding "Provides:
>XFree86-devel" to substitute X development libraries.  It
>shouldn't prevent them from co-habiting with the real
>XFree86-devel, or other substitutes, and RPMs that explicitly
>require XFree86-devel should still be buildable.

That is not an option unless the package containing the 
XFree86-devel virtual provides either contains all of the things 
that the current XFree86-devel has in it, or it has itself 
dependancies on every other package that contains those things.  

Here is the list of non-header, non lib .so files from 
XFree86-devel:

/usr/X11R6/bin/cxpm
/usr/X11R6/bin/gccmakedep
/usr/X11R6/bin/imake
/usr/X11R6/bin/makedepend
/usr/X11R6/bin/makeg
/usr/X11R6/bin/pswrap
/usr/X11R6/bin/rman
/usr/X11R6/bin/sxpm
/usr/X11R6/bin/xmkmf
/usr/X11R6/lib/X11/config/*  (lots and lots of stuff)
/usr/X11R6/man*  (manpages for all included apps and lib functions)

The manpages, .so, and .a files, would move into the
foo-lib<libname>-devel packages of course, however the above apps
above would be moved to some other package, probably
foo-X11-devel-utils or some other package name (need more thought
on that still).  Manpages could either be in
foo-X11-devel-docs or just foo-X11-docs or something, or they 
could be in each individual library's -devel package (which would 
be simplest as they reside along with the libraries themselves 
rather than all in one place).

The config/* stuff is the difficult part, which is a problem I 
don't want to remotely think about quite yet and I'm pretending 
it doesn't exist for now.  Keith Packard has a great idea for how 
to solve that, but it isn't a "done deal" yet.  It only affects 
things that are outside of XFree86/X11 that also compile with 
Imake mostly.  A problem to solve, but that's a problem for 
another rainy day in the future.  ;o)

For now I just want to focus on solving the genericization of X11 
API implementations in rpm context.  Imake and whatnot files 
above will probably be next on the list though, and perhaps even 
part of that fun ride.  ;o)

One other thing to consider, which I hadn't mentioned previously, 
is that there is a strong push to make /usr/X11R6 disappear in 
the future at some point, and many libs already are in /usr/lib 
such as fontconfig, and others.  If they move into /usr/lib, they 
still meet dependancies for being there, but the file names and 
paths to the libs probably wont be the same.  Not sure yet if we 
will be doing this sooner or later, but it's something to keep in 
mind also, even though it's not the problem being solved yet.

Thanks for the feedback, it's given some brain food think upon.

-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat





More information about the fedora-devel-list mailing list