RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc.
Mike A. Harris
mharris at redhat.com
Mon Feb 2 05:09:40 UTC 2004
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
More information about the fedora-devel-list
mailing list