Cnet cites Max: Red Hat wants Fedora to be a foundation for those who want to build their own Linux products on a Fedora foundation.
dwmw2 wrote: I'd love to see more functionality -- more _possibilities_ -- merged under the 'Fedora' umbrella.
There are more such statements from other people; the general idea is floating around for some time now in Fedora-land. I'm wondering if we should issue something like Max statement above as official goal for the next few Fedora-years, to have a target we can work towards.
But can Fedora really be a proper foundation for other distributions? What if somebody wants to create a complete OpenVZ or Linux-VServer distribution (just as example) with Fedora as a base *within* the Fedora-project to ensure updates and patches for all non-OpenVZ and non-Linux-Vserver stuff floating back and forth easily between this special spin (wich patches Fedora would not take) and the official Fedora? E.g. something similar to what OLPC in parts did?
Something like that afaics would be needed if we really want to be a proper foundation for other distros, as the "once Fedora-size fits all" is a good goal we should aim for with Fedora, but on the way to that sometimes special treatment and a semi-fork might be needed. Not to mention the old Who will ship the sources to fulfil the GPL-requirements problem that's still unsolved.
IOW: if we really want to be a proper foundation for other distributions there is much work to do afaics.
[Update 20071129-2110UTC]I just reused the word "foundation" (meant as in "base for a product/distribution" here) from the Cnet source. Do not confuse it with the "Fedora Foundation", a idea which was abandoned long ago.[/Update]
Dienstag, 20. November 2007
Sonntag, 11. November 2007
Problems updating kernels and kmods
I announced in on fedora-list@redhat.com and freeworld@livna.org already, but seems a lot of people ran into the problem and missed my post, so I put a slightly enhanced version of my post here as well:
While at it: looks like there is another bug in yum that affects kmods. In some situations the i586 kmod gets chosen to install, which tracks in the i586 kernel, which then leads to an error, as that has file conflicts with the i686 kernel. This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=346371
You can work around the problem by specifying which arch to install by running "yum install kmod-foo.i686".
F8 users with kmods will run into problems when updating to theSorry for the trouble. Note that we have seem other problem in F7 due to this problem in the past already as well. According to a comment in above bug report it looks like other kernel module packaging standards might be affected as well.
latest kernel from Fedora due to a problem in yum from F8 (at least
it looks like a bug in yum to me atm). See
https://bugzilla.redhat.com/show_bug.cgi?id=330711
for details. The problem looks like this:
# yum update
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package kernel.i686 0:2.6.23.1-49.fc8 set to be updated
---> Package kmod-nvidia-96xx.i686 0:96.43.01-17.lvn8 set to be updated
--> Processing Dependency: kmod-nvidia-96xx-2.6.23.1-49.fc8 for package: kmod-nvidia-96xx
--> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package: kmod-nvidia-96xx-2.6.23.1-42.fc8
--> Running transaction check
---> Package kmod-nvidia-96xx-2.6.23.1-49.fc8.i686 0:96.43.01-17.lvn8 set to be updated
--> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package: kmod-nvidia-96xx-2.6.23.1-42.fc8
--> Finished Dependency Resolution
If you run into this problem you can uninstall the kernel-modules for
the current kernel with this command :
rpm -e --nodeps $(rpm -qa 'kmod-*2.6.23*')
as workaround and then run yum update; you should get the new kernel and
the new kmods for it when running "yum update" afterwards.
While at it: looks like there is another bug in yum that affects kmods. In some situations the i586 kmod gets chosen to install, which tracks in the i586 kernel, which then leads to an error, as that has file conflicts with the i686 kernel. This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=346371
You can work around the problem by specifying which arch to install by running "yum install kmod-foo.i686".
Donnerstag, 1. November 2007
Testing new features in rawhide
Much talk about pulseaudio everywhere, so I wondered what it's all about and wanted to take a closer look (I likely should have done it weeks ago, but I was busy with other stuff...).
It wasn't really easy to find all the bits I need (I know, there were posts on fedora-devel-list or fedora-test-list weeks ago that explained what's needed, but well, that was months ago and they are not easy to find as well). Especially locating the volume control app made some trouble -- you see screenshots of it everywhere but that doesn't help much if you don't know the binary's name or the name of the package which contains it. Especially if you are so stupid as I was and just look in the packges with pulseaudio-prefix (hint for those that run into the same trap: the binary is called pavucontrol and it's package is called the same).
Those that install F8 freshly (once it's released) have more luck -- they will get the important bits by default. But rawhide testers (I updated this machine from F7 to rawhide months ago) didn't get it -- with IMHO kind of sucks, as a feature that will become by default isn't tested by default by regular rawhide users...
BTW: those that update from F7 to F8 with yum later won't get pulseaudio by default either...
It wasn't really easy to find all the bits I need (I know, there were posts on fedora-devel-list or fedora-test-list weeks ago that explained what's needed, but well, that was months ago and they are not easy to find as well). Especially locating the volume control app made some trouble -- you see screenshots of it everywhere but that doesn't help much if you don't know the binary's name or the name of the package which contains it. Especially if you are so stupid as I was and just look in the packges with pulseaudio-prefix (hint for those that run into the same trap: the binary is called pavucontrol and it's package is called the same).
Those that install F8 freshly (once it's released) have more luck -- they will get the important bits by default. But rawhide testers (I updated this machine from F7 to rawhide months ago) didn't get it -- with IMHO kind of sucks, as a feature that will become by default isn't tested by default by regular rawhide users...
BTW: those that update from F7 to F8 with yum later won't get pulseaudio by default either...
Abonnieren
Posts (Atom)