On Sat, 17 May 2003, Michael B Allen wrote: >to the three packages mentioned. All of which I seem to have or have >rebuilt from src.rpm. Rpmfind.net claims 2.4.18-3 provides kernel-drm. My >impression was that the remaining stuff is just a problem with RPM >dependencies. But if you know for certain a few packages that will >definately give me problems then please enlighten me before I run rpm >--nodeps and end up needing to back it off. > >"Upgrading" to RH 9 is not an option. This is my work machine and I don't >need any headaches. Right now the machine is rock solid and I'm going >to keep it that way. Backing off X is one thing but changing operating >systems is not acceptable and I'm sorry to hear RH is so quick to leave >people behind and EOL versions they just put out a year ago. I would >just like to use a flat panel I have but the current video doesn't seem >up to it so I was hoping improved support for my chip would help. Don't even get me started. You have absolutely no idea whatsoever the amount of engineering resources that are required to support releases for longer periods of time. First, I must apologize to everyone reading this for its length, however I need to speak my mind about a few things that I find a lot of people simply do not understand, and appreciate how complicated it is to produce a Linux distribution, and to keep it as high quality as possible, knowing what risks are good and what ones are bad, and knowing how to make the most efficient usage of your manpower and time resources, and to divide that time amongst future development of products, as well as maintenance of released products. I further apologize if this comes off as a rant to some people, as it is not intended in that way. Since email does not carry through emotional content very well, in order to understand my inflection/tonality here, picture me sitting in a nice cozy lazyboy chair, sipping a nice hot cup of Earl Grey tea, with a pleasant look on my face, and a polite tone to my voice. ;o) I'd offer you all a cup of Earl Grey to enjoy while reading my rambling below, however distance and technology prevent that. ;o) First, I should point out that the software comes at zero cost to those who want to obtain it that way, and upgrades are also optionally at zero cost. Some people do pay for the software and/or for RHN. Red Hat does not and has never promised any customers or users that any OS product would receive video driver updates once a month, or once every 6 months. Once the OS has shipped, it is shipped largely as-is. We provide security updates for the OS to handle security issues that arise, and we try to provide bugfix errata for major bugs that arise and to which we have the manpower resources and time to work on producing such errata. There is no guarantee of course that every single bug that gets reported can be fixed by us. We do try to provide as many fixes as possible however, and work is prioritized based on many factors not worth going into here. However, there are no good reasons why people can not upgrade their OS to a newer version in order to obtain support for new hardware. If hardware is trivial to add support for in an update, it often will happen, however non-trivial updates for new hardware are not always easy to do, and can require extensive engineering resources even to attempt. Nobody is obligated to pay for new OS versions of course, so they can be downloaded free of cost for those who can not, or do not want to pay for it. Not a bad deal at all for a full fledged operating system. And if they've got an RHN subscription already, after upgrading the OS, their entitlement can be changed to the new version free of charge as well. Some people wish that new XFree86 releases would be released as updates for existing OS releases every time a new release of X comes out, both so they can get the new XFree86 features, as well as the new XFree86 driver support and other enhancements. This was attempted once, as an experiment. I released XFree86 4.1.0 as an update to XFree86 4.0.3 for Red Hat Linux 7.1. I did this for 3 reasons: 1) Because the types of changes between the two releases did not change any core technology in any major way that might risk destabilization, or conflict with existing documentation of the OS, etc. 2) I wanted to be able to maintain one single set of XFree86 packages for multiple releases of the operating system, thus minimizing workload hopefully 3) I wanted to test how well an update like that would be received by people, the types of problems that might arise, and other problems, as well as getting good feedback. 4.1.0's changeset happend to not contain any major changes that I thought were likely to be too risky, and I'd been running 4.1.0 on my 7.1 box for quite some time already as were many others. The experiment was worth trying. Overall, the upgrade to 4.1.0 for RHL 7.1 worked out without any major catastrophes, but it wasn't without regression and wasn't without its share of angry users. I had been quite careful to try to minimize risks and retain as much packaging compatibility as possible, and deal with the numerous font related problems, DRM problems, driver change problems, and other issues as nicely as possible. Many people were glad to see the new release, and received it well, however not everyone did. Some users had working setups, which after upgrading to the new release - no longer had a working X setup. They were upset at the thought that we could possibly release an updated X package set which broke their setup. How could we possibly not have tested their specific video chip on their motherboard with the exact configuration options they were using? etc. for example. The answer of course being, that we don't have every piece of hardware, and even if we did have every motherboard, video card, laptop, system, monitor, mouse, keyboard, etc., we could never possibly have the time and manpower resources to even attempt to test a small fraction of all possible hardware out there. For video hardware, we'd have to try and test it in every color depth at every video resolution and do so both with and without DRI enabled, with and without dualhead, and with and without a bunch of other options, including testing Xvideo and the numerous other features that are present in XFree86. People just want stuff to work, and when it doesn't, then someone is going to get heat for it for sure. So yes, upgrading the X server may work great for many people, but it may totally screw up other people's setups too, and people get much more angry for having their setup broken from an update than they do starting out with a non working setup and not getting an update to fix it. Another *MAJOR* technical support issue, is the kernel DRM. DRM are the kernel modules which are used by the DRI code in XFree86 to perform direct rendering, and implement 3D acceleration. XFree86 can not work with just any old DRM, it requires the specific kernel DRM that was shipped as part of the source code of that specific XFree86 release, or a newer version of DRM which retains backward compatibility. This poses a significant technical, and technical support problem for Red Hat, and also for the users. If we hypothetically *wanted* to release an updated XFree86 version for an existing OS release, we absolutely can not just update X, and let DRM break. We *MUST* release a new kernel _first_ which contains the updated DRM. We must also try to guarantee that the new DRM works also with the older XFree86, so that users who do not want to upgrade X for whatever reason - are not forced to. And shipping multiple versions of DRM is also not feasible, as that requires supporting an ever expanding amount of software, with the same number of engineers. We can't support 3 different versions of X on 3 different kernels on one OS all at once, simply because some users want to upgrade and others do not, and all users want us to support whatever they are using. Another problem, as you are learning above, is that new versions of XFree86, require other new pieces of software, such as freetype, fontconfig, expat, and other software as well. In order to officially release all of those updated packages, we would technically have to make sure that any one of those packages can be updated on the system, and also work with the existing XFree86 in a compatible fashion, and that combinations of upgrades of the different pieces also work compatibly. The amount of quality assurance testing complexity that it would involve to properly test the massive number of compatibility permutations in upgrading that many components is mind numbing. One example I can think of, which I do not recall the specifics of, is that freetype exported some of it's internal interfaces in some releases, and that some stupid applications were using these internal interfaces and should not have been. A newer version of freetype fixed this by not exporting those interfaces. The applications which used them but should not have been of course would now be broken. So releasing an update of freetype, would mean releasing an update of the other apps that ended up breaking due to updating freetype. Imagine if that happened to be OpenOffice, Mozilla, and Nautilus. The number of packages quickly expands to consume all engineering and QA resources. The end result is that a large portion of the OS has been updated - just to upgrade something seemingly simple like XFree86. So, while people can upgrade XFree86 on their systems manually, and they might not have any problems personally with it, and may never happen to run a piece of software that broke due to one of the upgrades they did to get the new X installed, Red Hat, as a vendor will hear bad words from every user out there who does experience such a problem after such an update should an update be made available. XFree86 is an extremely large major piece of software. It is totally impossible to test it completely in any combination of automated or manual manner. In particular, the most dynamic thing is the video drivers, which may get upstream updates to fix a given bug, add a new feature, etc. and silently break another card nobody developing has, or nobody tested on. Perhaps that update just broke 16bit depth on C&T 65000 chip only, and all other C&T chips work fine. Who would ever know? To set up a test matrix to make sure these types of regressions are impossible would require being a company like IBM, and having every video vendor out there deeply interested in being involved and making sure their hardware works on as much hardware as possible. That just is not something feasible at this stage of the Linux game. And so, while companies such as Red Hat do make contributions to XFree86, fix bugs, and other companies do too, XFree86 largely remains developed by XFree86.org, the DRI project, and others in the community, and it is as high quality as it is handed over when branded with a new version number and release. That gets integrated into RPM packaging, patches dropped that are included now, new problems that arise get fixed hopefully, and the beta test process begins. >From a distribution beta test release perspective, as well as the ongoing rolling rawhide packages, they're not just a test of any given piece of software such as XFree86, but it is also a test of how that software integrates with all of the other software being beta tested. As many bugs get fixed as possible of course, but there are hundreds more bugs in XFree86 than are humanly possible to fix with the number of people working on it both in XFree86.org, the community, all distribution vendors shipping X, and beyond. There will always be bugs, and just like any other vendor or distro, we just try to ship as bug free a version as possible with the resources we have available, and to continue fixing problems that arise as best that can be done over time. To release an update of a major new XFree86 release on an old OS, means that while the video drivers are likely as well tested as the new release of the OS, and other things are likely well tested too, there is no *integration* testing done by the public on the OS as a whole. The risks are far to great at causing a domino effect of regression and requiring massive package updates for problems that could theoretically arise. Does this all sound too complicated? Probably, but this is just a very brief commentary on why as a /general rule/ new XFree86 releases do not get released for old OS versions. Whenever possible, drivers get updtated if it does not require significant re-engineering to retrofit them into an older X server as an update. I've done this in the packages of 4.2.0 in RHL 8.0: [mharris@xxxxx XFree86-4.2.1]$ ls -1 *cvs* XFree86-4.2.0-apm-driver-update-cvs-20020617.patch XFree86-4.2.0-ark-driver-update-cvs-20020617.patch XFree86-4.2.0-chips-driver-update-cvs-20020617.patch XFree86-4.2.0-cirrus-driver-update-cvs-20020617.patch XFree86-4.2.0-i740-driver-update-cvs-20020617.patch XFree86-4.2.0-i810-driver-update-cvs-20020617.patch XFree86-4.2.0-mkfontscale-xcvs-20020618.patch XFree86-4.2.0-pci-domains-from-cvs.patch XFree86-4.2.0-siliconmotion-driver-update-cvs-20020617.patch XFree86-4.2.0-trident-driver-update-cvs-20020617.patch There are other updates as well. However if someone finds that their chip is not supported, and will not be supported in any official OS update of XFree86, and they are told to upgrade to a new OS version for support for that chip - it is for a really good reason. It means that adding support for that chip, is significantly complex that it would require major engineering resources, possibly even ending up forking the X codebase in a major way to even get it to work. Intel i845 graphics is a good example of this. i845 requires invasive kernel changes, as well as very invasive X server changes (compared to 4.2.0 that is), and the technical specifications for the hardware aren't even possible if someone did plan on doing it. So that is why i845 will not ever be supported in Red Hat Linux < 9. If I could make i845 work in RHL 8.0 in 2-3 days worth of work, then it might be feasible to try to do that. It is not easily possible however, and so it will not happen. There are massive number more things that are much more important for me to be working on, than wasting massive ammount of time trying to backport driver code without the hardware and without the docs, and with a huge amount of dependant code needing backporting as well. It's easier to just upgrade the whole X server than maintain a massively forked backport. And I've covered the reasons why an X server update is generally not feasible above. You'll notice in the patches above there is: XFree86-4.2.0-i810-driver-update-cvs-20020617.patch That was an attempt to backport the existing i845 video support in XFree86 CVS as of June 2002. It did not work at all for the majority of people, but it worked better than nothing for a few people, so it was kept, and it shipped in Red Hat Linux 8.0. It was unsupported of course, and remains unsupported. Nonetheless, it was an attempt I had made voluntarily on my own personal time to try and get i845 running in any useable manner on XFree86 4.2.0 in Red Hat Linux 8.0, and without having the video hardware to even test with, and without any knowledge of the hardware since the specs were not publically nor privately available. I had originally planned on trying to improve this in my own spare time also, as I really couldn't justify spending company time on doing what was largely a hack, and not something that could be considered "supported". The majority of feedback I received since then however about i845 support from users and customers however has been extremely negative - ranting and raving. People demanding that we support i845, etc. and going ballistic when I tell them it is not supported, and that we wont ever support that video hardware on those specific products. I've covered above why that support is not feasible to do, and not going to happen, and that people need to upgrade to Red Hat Linux 9 if they want officially supported i845 video. If i845 could be made to work well in Red Hat Linux 8.0 or earlier without a lot of effort, I probably would have gladly tried to do so by now, even in my own time. Due to the amount of complaining and negativity I've received however, for something that is unsupported, and not feasible to try to support, I dropped any plans to attempt doing this, as in my personal time as a volunteer - as there wasn't anything positive or good that I was receiving about it. I've used i845 as a single example here, however there are lots of other examples which could be used. Some people want 3D support for Radeon 8500 in Red Hat Linux 8.0 for example. Essentially, the only sane way to do that, is with XFree86 4.3.0. Ditto for many other hardware support related issues. Soon there will be XFree86 4.1.0 updates forthcoming for Red Hat Linux 7.1, 7.2 and the AS/AW/WS enterprise line of products. These updates contain some new video hardware updates that I was able to work on and integrate, including support for all remaining Rage 128 video chipsets, Savage driver update to the latest bits, some Radeon updates, Nvidia Quadro updates, and others. There will be XFree86 4.2.1 updates for both Red Hat Linux 7.3 and 8.0 of which contain identical support and bug fixes now (but different RPM packaging). There is a new savage driver, R128 updates as above for 4.1.0, FireGL 8700/8800 support update, and many many other updates as well. There are still some driver and other updates which can be done without much effort for 4.2.1 and 4.1.0 however not a heck of a lot without going into major effort for little to no benefit. After this upcoming XFree86 update is released, both 4.1.0 and 4.2.1 will essentially go into security-fixes only phase, and updates will only come out when there is a security issue found that requires an update. I will try to cram any stable sane bugfixes into those updates as well, but people experiencing problems in those releases should expect that only security fixes will occur from now on for those releases, and that OS upgrades will be required in most cases where new hardware is unsupported in the given OS release currently. Also, before someone asks me.. Yes, this will be an XFree86 4.2.0 -> 4.2.1 version update for Red Hat Linux 7.3 and 8.0, and some people may see this as contradictory to what I've said above (and below) about version upgrades. XFree86 4.2.1 is only a cosmetic version number change that was made by XFree86.org for a security update. XFree86 4.2.0 and 4.2.1 are identical support wise other than 4.2.1 containing a security fix (which we shipped as a patch to 4.2.0) and various other bug fixes which we've been shipping all along as patches to 4.2.0. So while this is a version change, it is minor and only a few small patches different from our existing 4.2.0 packages not counting all of the new bugfixes I've rolled in personally of course. ;o) I will also be moving XFree86 packaging to a much more modular set of packages sometime in the future, with the intent being to be able to provide more frequent updates of certain pieces without having to roll out a massive 150Mb errata to fix a driver. It'll be a gradual packaging shift that happens over time rather than a major break in packaging strategy in order to minimize user problems and whatnot. I would eventually like to see the drivers split into their own packages and be able to be updated independantly, and I'd like to see the driver sources compatible across server releases in some manner. Those things require buy in from the upstream X supplier however in order to truely be feasible. >If there are no objections I'm going to try running with --nodeps. Last >call! Stop me now if you know better! Go nuts if you must, but do so realizing that dependancies exist for a reason. After running with "--nodeps", you can fully expect whatever software required the given dependancies you've chosen to ignore - to break. That's not specific to XFree86 of course, but is just the fact that dependancies are tracked by RPM for a reason, and when you use --nodeps you are purposefully saying "I know that this software *requires* this other thing in order to work, but I don't care, install it broken anyway". >Mike >[who fortunately uses Pine] Not so fortunate actually... pine was just officially removed from the distribution in rawhide. Of course, I'll be maintaining pine rpms for RHL unofficially on people.redhat.com though, because I am such a nice guy. ;o) Anyway, I hope that some people out there got something beneficial from my above attempt to rationalize XFree86 package management and release engineering, and I hope people look at this much deeper in the future and with more perspective into the complexities involved in maintaining distribution software, and providing stable updates to the userbase, which are tested as much as can be reasonably done. I hope people realize now that while upgrading any major software component such as XFree86 on one's own personal system, may seem to come off without any problems, that for a vendor to do it, a lot more work must go into the process than just doing it and saying "it works for me". A vendor has a fair amount of responsibility to its customers to not release software updates which may cause any large risks to any particular part of its installed userbase, and also to use its engineering and time resources as wisely as possible, balancing future development with maintenance and support. In the realm of video, that often means users will be required to upgrade their OS in order to stay up to date with the latest video hardware support available. It's not the ideal solution, but it is the only really feasible one given the parameters and contraints. One again, my apologies for the long book... would you like another cup of Earl Grey? ;o) -- Mike A. Harris _______________________________________________ xfree86-list mailing list xfree86-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/xfree86-list IRC: #xfree86 on irc.redhat.com
