On Wed, Jul 14, 2010 at 10:58 PM, Tim <ignored_mailbox@xxxxxxxxxxxx> wrote: > On Wed, 2010-07-14 at 11:38 -0700, Rick Stevens wrote: >> I can see two possible solutions. One would take the form of yum >> checking to see if kmods are needed for a new kernel on the system and >> not downloading the kernel if the kmods aren't available. > > I thought that was already done with the skip-broken option/plugin? > Where an update run would only bring in all the things that could be > installed. The next run would do whatever else it omitted before, if > the modules had been built in the meantime. That's not how it works and not what --skip-broken does. That option skips trying to update packages for which there are broken dependencies. In this case, there are no broken dependencies. The new kernel is available, installable, and all packages on which it depends are available and installable. The Fedora kernel does not have a dependency defined for the proprietary nVidia driver, so it's not considered broken when it "can't" be updated. In response to the wider discussion (not specifically to you, Tim), asking the Fedora Project to work around brokenness the user introduces themselves through the use of 3rd party software is entirely unreasonable. When you upgrade the core of your operating system, regardless of vendor, there is no expectation that 3rd party software or drivers will continue to work. It is up to you, the user, to ensure that 3rd party software you depend on works in your new environment. If dealing with kernel upgrades that break 3rd party software is not for you, and you don't know how to work around it, then either find out how or accept that Fedora may not be what you're looking for. This is documented in the 4 Foundations of the Fedora Project: First [ . . . ] We recognize that there is also a place for long-term stability in the Linux ecosystem, and that there are a variety of community-oriented and business-oriented Linux distributions available to serve that need. However, the Fedora Project's goal of advancing free software dictates that the Fedora Project itself pursue a strategy that preserves the forward momentum of our technical, collateral, and community-building progress. Fedora always aims to provide the future, first. If you're relying on slow to release proprietary 3rd party software, well, the Fedora train has already left the station. If you need something that's going to provide an unchanging framework in which to run your 3rd party software, "there are a variety of community-oriented and business-oriented Linux distributions that serve that need." Likewise, also documented in the 4 Foundations of the project, is the concept of Freedom, and this commitment to Freedom precludes the Project from devoting (or wasting) time on ensuring that proprietary 3rd party kmods work with the operating system: Freedom [ . . . ] Freedom represents dedication to free software and content. We believe that advancing software and content freedom is a central goal for the Fedora Project, and that we should accomplish that goal through the use of the software and content we promote. By including free alternatives to proprietary code and content, we can improve the overall state of free and open source software and content, and limit the effects of proprietary or patent encumbered code on the Project. Sometimes this goal prevents us from taking the easy way out by including proprietary or patent encumbered software in Fedora, or using those kinds of products in our other project work. If this commitment to Free software is something that you find inconvenient or problematic, then again, Fedora may not be the solution you are looking for. However, if you feel the overall goals of the Fedora project are worth supporting, but find you rely on proprietary 3rd party software, then the onus is on you to educate yourself on how to make that happen. -- Chris -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
