On Fri, 9 Aug 2002, Thomas Dodd wrote:
>Date: Fri, 09 Aug 2002 09:27:35 -0500
>From: Thomas Dodd <ted@...>
>To: DRI devel list <dri-devel@...>
>Cc: Mike A. Harris <mharris@...>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Subject: Re: [Dri-devel] DRI/DRM handshake API
>Mike A. Harris wrote:
>>That's not possible. Updates are provided in rpm packages, and
>>rpm packages are produced from a single source. When we update
>>any part of a package, all new subpackages are released
>Perhaps that should change?
That is very easy for an outsider to say, and very easy to solve
in theory. Unfortunately that does not solve the problem. We
need a sane way of packaging up all of our software which is
consistent across the operating system. We also need a method of
defining what we support, and minimizing the support matrix to a
sane common ground.
For the Red Hat Linux distribution, that means an XFree86 build
is only supported if all XFree86 components are installed on a
system from the same Red Hat supplied build. ie:
XFree86-*4.2.0-8 (as shipped with RHL 7.3).
Users are always free to mix and match packages, and always will
be able to. They'll also be able to supply their own drivers,
and to use DRI-CVS, or whatever. Of course we do not support
that, but we certainly allow that, and will always do so.
Our packaging however must always be sane and maintainable by us.
I've made various improvements to our packaging since RHL 7.0,
and will continue to make more in new releases. The goal is
maintainability and supportability, as well as flexibility.
>Part of the point of DRi and XFree86-4 wqs
>to allow seperation of drivers from the rest of
>the package. I think ATI does this with their drivers,
>NVIDIA got it partially, they just didn't use DRI.
>Why no make the 2D/3D drivers seperate packages?
>Jose does it with it snapshot builds. I can get the latest
>r128 or radeon drivers for X, without grabbing a whole
>new X release. I can get kernel modules without a new,
>kernel like tulip, or NTFS.
That is something that is possible, and which I have thought
about for a while now. However, before that can be done, we need
to have the proper configuration infrastructure in place to
handle the changes. I do not want to just split out the drivers
into a subpackage of X and leave it at that, as I think that is
just a hack. I want to implement configuration infrastructure
that can manage such split up packages in a sane way which is
very user friendly, including asking the user to insert their
CDROM and/or their Windows CD and/or give me a URL and/or
retrieve new packages via up2date and/or FTP and/or the web,
To split out the drivers without this infrastructure in place,
would end up greatly increasing the amount of package maintenance
and technical support overhead. There are many bugs reported in
bugzilla as it is now. I can tell from looking at the XFree86
log file which Red Hat XFree86 release is being used, and I can
easily try to reproduce that user's setup by configuring a
machine with the same version of X locally. With drivers split
out into different packages, it is possible a user has XFree86
4.2.0-8 installed, but has 4.2.0-15 drivers installed, or even
4.1.0-15 for all I know. There is no easy way for me to know
what they're using, and it increases the confusion and time to
debug and troubleshoot a given problem.
In order to remedy that, what I would like to do, is start gpg
signing the modules with a randomly generated key at build time,
and having the X server check the signature of the modules at
runtime. If the module is an authentic module that we've
supplied with that version-release of X, then a log message to
that effect is printed to the XFree86 log file. If it is not an
authentic module from our build, then a message is printed to the
log file indicating it is not an officially supported
configuration. In all cases, the module will be loaded and used,
but at least then we'd have a way to judge incoming bug reports
wether or not they're using a valid supported configuration or
not. People can then use unsupported configurations, but just
can't expect us to debug their custom setup.
>I think the RPMs need to be more modular.
I agree, with the above stipulations.
>Or at least the updates. A fix in a kernel driver
>should only need the new driver, not the whole
>kernel and all the drivers.
Again, that is very easy to *say*. It totally and completely
does not handle the problems of technical support, nor of package
maintenance. It is a total tech support nightmare to have users
using one kernel, with modules from another kernel, an X server,
with one module from one release, another module from some other
That is exactly what WOULD happen if things were split up without
any mechanism for us being able to validate bug reports for
supported configurations. Even then, if we could validate bug
reports, it is still a major burden to have to walk people
through determining if their configuration is supported to tell
them "sorry, your configuration is not supported" and close a bug
report - to have the person pissed off and yelling "WHAT DO YOU
MEAN IT ISNT SUPPORTED!!!!!!"
>Same for X. New/updated drivers are released seperately. When A
>new release like 4.2.0->4.2.1 comes along, you do a full
>release. Or security fixes to core sections, that require
>rebuilding new drivers.
That isn't acceptable for the reasons outlined above. It just
does not provide supportable/maintainable software
configurations. The installation permutations are far too great,
and would require a large amount of technical support resources,
which far and large end up wasted troubleshooting users poor
>Most of the changes in the XF-4.2.0 packages look like
>driver/font changes which should have had the ability
>to be only a few files replaced.
Some of them are, yes. Some of them are much more than that
>Like the ATI-vt-switch fix. 2 drivers, like 2 files
>each. *_dri.so and *_drv.o, maybe the kernel drm module,
>but you X change didn't need a new kernel. You even
>posted only the X dri.so and drv.o files. Just package them.
You CANT just repackage them. The packages MUST be properly
built and packaged in one buildsystem using the same toolchain,
in order to have reproduceability, and quality assurance. The
method that you describe would work ok ad hoc on an end user
compiled/maintained system, however it does not have the
reproduceability or maintainability which is required in a major
Linux distribution. We HAVE to be able to be account for the
software builds, and know what was in the buildsystem at the time
a package was built. XFree86 and other software builds MUST be
unified in this respect. Anything else is just insane.
>Make them like XF86-drv-update-<xversion>-<release>. And new
>XF86 releases have those updates, and obsolete the
>XF86-drv-update rpms for <xversion> < <new xversion>
I don't think you've ever packaged RPM packages before or you'd
know that that just is not possible. That's not a flaw either,
it is a very much intentional part of distribution engineering.
>So the XF86 packages remain, but driver updates can be dropped in.
An absolutely unsupportable tech support nightmare. That would
work fine for a distribution which is thrown over the fence on
the internet with no bug tracker or tech support available by the
distribution creator, however it absolutely is not a sane way of
providing software to customers/users and being able to handle
all of the permutations of technical support problems that arise.
Once the X server modules are signed, and the X server checks
them, this is much more possible to release new full XFree86
releases with drivers broken out into a drivers package, or
individual driver packages even, and allow users to update a
driver or various modules individually. If the user has a
problem using X, and reports a bug, unless their XFree86
installation is all one unified XFree86 release - it is
unsupported. "Please reproduce using all packages from one
unified XFree86 package set."
Again - asking people to do that, even with the infrastructure in
place, would still increase tech support burden a LOT. It is
certainly not something that will happen in the immediate future,
but it is something I do want to do at some point - but only if
it is going to be beneficial to both the users of the software
AND the developer maintaining the package (me), the distribution,
and the community.
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer Ontario, Canada, P6C 5B3
Red Hat Inc.