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

[Mike A. Harris]

On Sun, 8 Feb 2004, Bill Nottingham wrote:

>> >Sounds good to me. I'd love per chipset packaging so that for
>> >example XFree86-ati-radeon-blah contained the radeon driver, dri .so and
>> >related bits, but that I can see is a good deal harder to get right
>> 
>> That is something I definitely want to do in the future also.  
>
>One of the great benefits of how the OS is distributed now is that,
>for any hardware supported by the OS, they don't need to go looking
>for their CDs, or start hitting the network, etc. to get that hardware
>supported.
>
>If you go down this road, you all of a sudden change that, and
>that's really not good. You also end up having to tie a good deal
>of logic into installation programs just to get the right package
>installed.

I disagree.  I think that the "keep it the same forever" approach 
does not allow existing problems with the current approach to 
ever be solved.

There's also no good reason to believe that packaging things in 
another way will automatically create the problems you've 
described.  For example, the installer can force all drivers to 
be installed, and not permit someone to deselect them at install 
time.  It works well in other OS's this way, and there's no 
reason it can't work in Linux either.

Unlike the kernel, which doesn't have a stable binary module ABI, 
the X server does, so there's no reason why driver modules can't 
be packaged separately and updated individually as the need 
arises.

With the current method of putting all drivers into one binary
blob module with the X server and everything else, a one line
driver fix that solves a problem for users but wasnt found until
after the OS is released, generally means the user will have to
pick up the fix from rawhide, or some one-off unofficial build I
do, or they'll have to wait 6 months for the next XFree86 
security erratum or something, or the next OS release.

We've gotten by "good enough" with that approach, but I 
personally don't believe "good enough" is good enough.  I want to 
see us do better here, and I think it is both possible to release 
individual video driver updates, and that it's in our best 
interest to do so, and to be able to do so.

Nobody is forced to put in their CDROM, nor to download them via 
a network.  They do so only if they wish to have that additional 
option.

Right now a user who has video driver problems options include:

- Download a new XFree86 update from Red Hat (if any)

They have to download up to 150 or more megabytes of largely
duplicated binaries, drivers, fonts, and other stuff.  Most of
this stuff hasn't even changed at all.  If they were just doing
this for the 1Mb driver update, this is quite wasteful on their
bandwidth, our bandwidth, disk space on both sides, and is IMHO a 
very poor solution.


- Wait for the next Red Hat official XFree86 update, which may or 
  may not even solve their problem.

We don't release driver updates now, just full XFree86 updates, 
however a given driver may or may not even have been updated.  
Many users download new releases in hopes that it may have an 
updated driver, even if that driver is identical.  They're not 
even aware generally wether or not a driver was updated.  There's 
no easy non-technical way for them to find out.


- Download binary drivers from XFree86.org or somewhere else.

Not a Red Hat "supported" option, doesn't integrate with the 
distribution or our tools.  An ad-hoc workaround at best, until 
their vendor (us) has a better solution for them, which currently 
can be months, if not even longer.


There are /many/ cases in which I could fix a driver, or apply
patches from upstream, etc. and have a new driver tested in short
order via unofficial or "testing" channels, and once enough 
feedback has been received, I could easily release a "driver 
update" rpm, containing just the new driver.  up2date and/or yum 
makes it trivial for a user to do updates.  In most cases, all 
the user needs to do then, is restart XFree86 without 
reconfiguring anything and they're using the new driver.  I think 
that is a very very desireable goal, and a 1Mb driver rpm beats a 
150Mb half hour RHN update.  ;o)



>> Also, the driver rpms should have a metadata file included with 
>> them which is essentially like a Windows .INF file, which drops 
>> into a predefined /usr/share/something dir and informs our 
>> config tools what hardware this new driver supports, etc.  
>> Basically a modularized replacement for the ancient Cards 
>> database, and pcitable, where that information is now stored in a 
>> metadata file accompanying the driver.
>
>Well, currently, the drivers all have information on what hardware
>they support included. *Unlike* the kernel drivers, they don't
>export this in a sane manner.

The drivers can be dlopen()'d and their functions called by other 
software.  I've never personally tried to do this, but IIRC, the 
xf86cfg tool does so.  I'd have to confirm that however.  I'm not 
sure wether that would be the best approach or not though, but 
it's something worthy of more research.

My basic premise above, is that the current mechanism for 
packaging, supplying, maintaining, distributing video drivers and 
updates to users, is not "the best we can do".  I _know_ we can 
do _much_ better, and I believe that there are a lot of benefits 
both to myself as the maintainer of XFree86, to end users who 
would like the possibility of getting driver updates sooner than 
once every 6-12 months, and to Red Hat for having a better 
solution for customers that meets their needs in a way much 
closer to what other mainstream operating systems can provide.

I don't claim that it is a cakewalk to get there however, nor 
that there are no obstacles.  There are obviously some important 
issues that would need to be ironed out, including things like 
the installer, the config tools, and other bits.

But if we let things stay as they are now, and never even try to
provide a better solution, then we wont ever _have_ a better
solution.

Rather than having people resist such changes and just state some
theoretical problems that might exist if we were to separate out
drivers, I would prefer it if people embraced the idea with the 
thought "this would be good for us all around", and then thought 
of some real problems it might cause, and then proposed some 
ideas for how we might go about solving them.

For the "the driver didn't get installed when I installed the OS" 
problem, the solution is simple.  We benevolently install all of 
the drivers without giving anyone any say during installation 
wether or not they want them all.

Also, just for the record... this "split the drivers into 
separate rpms" idea, is not something I'm trying to force into 
Fedora Core 2, possibly not even FC3.  It's a "we need to get 
there sometime down the road, how do we go about planning to get 
there now" idea.



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