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

[Mike A. Harris]

This is a Request For Comments intended to help determine the
best /long term/ solution over time for a problem developers and
rpm packagers will face with multiple alternative X11
implementations being available in RPM packaged format in the
future.  This is not intended to be a short term or rushed 
solution, but one in which developers will be able to migrate rpm 
packages to using over time.  It is my hope that the time period 
would be short, but it can theoretically be as long as is 
necessary, as this is just a discussion for now.


Problem scenario:

Currently, the XFree86 implementation of X11 has all of the 
libraries present in the package XFree86-libs, and all of the 
necessary development headers are included in XFree86-devel.

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

This is suboptimal for packaging however, as it makes a bad 
assumption that there is only a single implementation of X11 
APIs, and that only this implementation can be used to satisfy 
the dependancies of applications needing to link to X libraries.

In order to facilitate alternate X11 implementations, these hard 
coded dependancies in RPM spec files need to be changed to be 
more generic, rather than implementation specific.  This does 
pose a rather large problem however, as the entire base of OSS 
software rpms out there which link to X libraries pretty much all 
assume there is one and only one implementation of X11 which will 
be in rpm format with longevity.

The problems of course only arise when considering an actual 
alternative implementation of these APIs, such as the 
freedesktop.org X libraries.  (xlibs CVS module).  When these 
libraries are packaged up, they could be packaged in individual 
rpm packages (my current plan for now), or they could be put in 
one bigger package.  Either way, this causes large changes to 
various assumptions on dependancies.

While there is no easy one-stop-shopping solution which can 
work around all of the possible problems and annoyances that 
will occur when alternate implementations of X11 are rpm 
packaged and made available, there are probably different ways 
to achieve the end goal, which is to:

1) Allow multiple X11 implemenations to be available in rpm 
   packaging, and be substituted with each other easily.

2) Allow X11 software to compile, link, build and produce 
   packages irrespective of which implemenation is present.  This 
   is important, because X11 is a standard, and so any compliant 
   implementation should be substitutable, at least for the bits 
   that are actually official standards.

3) Allow X11 software binary rpm packages which were compiled 
   with any X11 implementation, to install cleanly on a system 
   which has any X11 implementation installed.  Of course, in 
   this particular case, only "official standard" parts of the 
   given X11 implementation should be interchangeable 100%, 
   however implementation specific features may require 
   additional dependancies.

I've thought of various approaches to solving this problem, and 
there are rather large tradeoffs no matter which path is chosen.  
I personally believe that the best solution is the one that gives 
the greatest long-term benefits, and is "future proof".  A best 
long-term solution however may have additional short term growing 
pains which are necessary in order to get to the long term gains.

Here are some example problems:

Package "Requires: XFree86-libs" to get libX11 and libXaw.  It 
currently "BuildRequires: XFree86-devel" to meet dependancies.
We now want this package to build and work with the alternative X 
library implementation "freedesktop-libX11" and 
"freedesktop-libXaw".  Since only one implementation could be 
installed at a given time in a clean manner (we'll make that 
assumption anyway), by changing every rpm to use:

	Requires: freedesktop-libXaw
	BuildRequires: freedesktop-libXaw-devel

That just substitutes one poor assumption problem for another 
equally bad problem.  It doesn't solve the real problem, which is 
that multiple X11 implementations can exist, and any particular 
one could be present on the system theoretically.

Another possibility, would be to have something do a virtual 
provide for XFree86-libs and XFree86-devel.  For example, we 
could have a fake XFree86-libs package which does nothing more 
than "Requires: freedesktop-libX11" etc. and same for the -devel 
package

Problem with that is, that would allow a real quick short term
solution which is quite an ugly hack, and it still makes bad 
assumptions and isn't really IMHO "future proof", which as stated 
earlier is one of the main goals I wish to achieve from this.


Proposed Solution:

After much thought, my own proposed solution, is to do the 
following:

- Create a number of new "virtual Provides:" in the XFree86 rpm
  spec file in the XFree86-libs and XFree86-devel packages 
  respectively.  Essentially there would be one new virtual 
  provide for each library, and perhaps for developmental 
  utilities necessary for X development also, which are presently 
  in XFree86-devel.

After testing this and working out any quirks by experimenting 
with some out-of-tree packages, by changing their Requires and 
BuildRequires to point to the new virtual provides instead, any 
major issues could be worked out before anything were to be 
developer-visible.

Example for the package freedesktop-libX11 would be:

Provides: libX11 = %{version}

for freedesktop-libX11-devel:

Provides: libX11-devel = %{version}
Requires: freedesktop-libX11 = %{version}

At this point, rpm packagers could begin to change their packages 
at will to use the new virtual provides instead of relying on the 
implementation specific XFree86-libs and XFree86-devel packages 
explicitly.  Since both XFree86-libs and XFree86-devel would 
continue to exist for some period of time at least, no packages 
should break right away, and developers would have plenty of time 
to fix the packages to use the virtual provides.  Announcements 
would be sent out to as many forums deemed necessary to try to 
reach rpm packagers who would be affected and need to modify 
their rpms.

This would amount to determining exactly _which_ X11 libraries an 
rpm package is really dependant on at build time, and then 
listing their virtual requires:

Xawtv:
Requires: libX11
BuildRequires: libX11-devel

Packages in the distribution itself could be modified over time
by their respective maintainers, or en-masse by a few people
trying to "solve the problem all at once" with minimal impact on
others internally.  Likewise a similar process could occur with 
external packages such as Fedora Extras/fedora.us, freshrpms.net, 
and other rpm factories.  This could very largely be scripted to 
find the rpms needing changes, and most of the short-term 
problems would be solveable IMHO without much difficulty, 
especially since the existing XFree86-devel and XFree86-libs 
packages existing still and also containing the right collection 
of virtual provides.

This way, if a system has an alternative X11 implementation 
installed in the future, it should be harmonious.  Of course 
there would likely be packages found which never got updated over 
time, but that's impossible to avoid 100%.  Those remaining 
packages could be updated at that point, and it would still be 
possible to provide a fake XFree86-devel and/or XFree86-libs 
package if there was any significant problem caused by this 
solution.

One could then also for example, drop in rpm packages from X.org, 
to use their implementation, and have Xorg-libX11 providing the 
virtual libX11 package.

I believe that this solution has a lot of merits, although as 
stated above, there would be some growing pains in some cases, 
however that could be mitigated by continuing to provide the 
faked XFree86-foo packages over time, and trying to find and fix 
problematic packages as time and whatnot permits, rather than 
being forced to do it right away.

I look forward to hearing developmental comments and feedback,
both from other developers at Red Hat, as well as community
developers working on/with Fedora project, Freshrpms.net,
rpmfind.net, and other rpm repositories out there, as well as
feedback from individual project developers who maintain rpm
packages that have dependancies on X11.

Alternative ideas, and/or modifications to my proposal above are 
also encouraged.  Please try to look at the long term aspects and 
benefits and not focus on short term drawbacks/problems, and 
please make suggestions that try to remain as X11 implementation 
neutral as possible, as I believe that is an important goal.

I look forward to hearing everyone's feedback and comments.  

Thanks in advance.


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