I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686 0:2.6.18-1.2798.fc6 Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686 0:2.6.18-1.2798.fc6 Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
http://docs.fedoraproject.org/release-notes/fc5/#id2942737
Rahul
On 5/6/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686 0:2.6.18-1.2798.fc6 Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
http://docs.fedoraproject.org/release-notes/fc5/#id2942737
Rahul
I entered a RFE (request for enhancement) for the installonlyn plugin asking for the ability to shield/retain specific version of the kernel. I was shot down. Upon reflection I realized that yum updates worked fine before installonlyn was developed. In my case there is no need for it. If I find too many kernels are installed I just remove those I do not want. So follow the advice of the release notes :
"A yum plugin written by Red Hat developers is provided by default within the yum package which only retains the latest two kernels in addition to the one being installed when you perform updates on your system. This feature can be fine tuned to retain more or less kernels or disabled entirely through the /etc/yum/pluginconf.d/installonlyn.conf file."
The phrase "in addition to" is incorrect. It should be "includes". You get a maximum of two kernels; that is, if you already have two kernels installed then an update will remove the oldest.
Edit installonlyn.conf and either disable it or change the number of kernels to keep.
Kam Leo wrote:
I entered a RFE (request for enhancement) for the installonlyn plugin asking for the ability to shield/retain specific version of the kernel. I was shot down.
Right. That's outside the scope of the plugin.
Upon reflection I realized that yum updates
worked fine before installonlyn was developed. In my case there is no need for it. If I find too many kernels are installed I just remove those I do not want.
Of course you will. Others find it useful. absolute statements are no good here.
The phrase "in addition to" is incorrect. It should be "includes". You get a maximum of two kernels; that is, if you already have two kernels installed then an update will remove the oldest.
Behavior got changed and I am not a native speaker. We aren't going to fix the FC5 release notes after all this period. It provides the gist of the information that is required to understand what's going on and change the configuration if required. That should serve the purpose.
Rahul
On 5/6/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
I entered a RFE (request for enhancement) for the installonlyn plugin asking for the ability to shield/retain specific version of the kernel. I was shot down.
Right. That's outside the scope of the plugin.
Upon reflection I realized that yum updates
worked fine before installonlyn was developed. In my case there is no need for it. If I find too many kernels are installed I just remove those I do not want.
Of course you will. Others find it useful. absolute statements are no good here.
The phrase "in addition to" is incorrect. It should be "includes". You get a maximum of two kernels; that is, if you already have two kernels installed then an update will remove the oldest.
Behavior got changed and I am not a native speaker. We aren't going to fix the FC5 release notes after all this period. It provides the gist of the information that is required to understand what's going on and change the configuration if required. That should serve the purpose.
I am not faulting your language abilities. It is probably better than mine.You provided the reference. I corrected the information referenced.
By the way, it is unfortunate that the FC5 release note is the only place where this is documented. I find no correction in any Fedora Core on-line documentation regarding the change in behavior. It certainly did not make it's way into the FC6 release notes. If the change did not make it into the documentation of following distribution and the FC5 on-line release notes were not updated how do end-users get informed?
Rahul
Kam Leo wrote:
By the way, it is unfortunate that the FC5 release note is the only place where this is documented. I find no correction in any Fedora Core on-line documentation regarding the change in behavior. It certainly did not make it's way into the FC6 release notes. If the change did not make it into the documentation of following distribution and the FC5 on-line release notes were not updated how do end-users get informed?
I think that the job of the release notes to most part is to convey information on what has changed on that release compared to the previous one. Continuing to carry forward all relevant changes that might be useful might make it too long for anyone to bother to read. We already ran into the problem in FC5. This is at the moment a attempt to find balance.
If you got better solutions, suggest them.
Rahul
Kam Leo wrote (about the installonlyn yum plugin):
You get a maximum of two kernels; that is, if you already have two kernels installed then an update will remove the oldest.
I understand that (and in my experience) this is incorrect. The plugin will not remove the currently booted kernel. So if n=2 (the default) then an update will remove whichever one you are not booted into.
This may be close enough to what you are looking for. It is intended to ensure there always is a working kernel available for booting.
James.
On 5/6/07, James Wilkinson fedora@aprilcottage.co.uk wrote:
Kam Leo wrote (about the installonlyn yum plugin):
You get a maximum of two kernels; that is, if you already have two kernels installed then an update will remove the oldest.
I understand that (and in my experience) this is incorrect. The plugin will not remove the currently booted kernel. So if n=2 (the default) then an update will remove whichever one you are not booted into.
So the "only retains the latest two kernels" in the release notes is also not correct. They really need to correct the write-up on this plugin.
This may be close enough to what you are looking for. It is intended to ensure there always is a working kernel available for booting.
James.
On Sunday 06 May 2007 22:16, Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686 0:2.6.18-1.2798.fc6 Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
-- select 'mmarques' || '@' || 'unl.edu.ar' AS email;
Martín Marqués | Programador, DBA Centro de Telemática | Administrador Universidad Nacional del Litoral
Yum by default only keeps 2 kernels. If you go to /etc/yum, and I'm running FC2 at the moment so can't check, but in /etc/yum IIRC there are 2 directories. One has to do with plugins. You want the installonlyn plugin. In this one change the line "enable=1" to "enable=0". Now all your kernels will be saved, and if you want to remove specific kernels you can do it using yumex.
I use Apt, not Yum, and personally think that this default behaviour of Yum is potentially risky.
For example. You have a kernel installed when you installed FC6, and this works ok. You do a yum update, and a newer kernel is installed. For some reason this kernel does not work. Some time later after another yum update, another kernel update is installed, which removes your original kernel. If the latest kernel doesn't work, you are stuffed, as your original kernel, which did work has been removed by yum.
Personally I'm glad that I use Apt. I don't have to suffer this Yum stuff.
1: Apt keeps all kernels. You decide which ones you want to remove.
2: Yum trashes all the downloaded files as default, once the update is completed. Apt saves them as default in /var/cache/apt/archives. If you are getting a bit close to critical on harddrive space , and don't need the archives, you can do an apt-get clean, and it will send them to the trash, but at least you are in control.
Allright having the cache saved as default does consume some harddrive space. I'm on dialup, and may want to install another instance of FC6 on another partition. It makes sense to retain the cache. It not only saves wasting Internet bandwidth, but also time on my dialup connection. I won't rant on any more, but do think that it would be more convenient for users if Yum:
1: Had the installonlyn plugin set as enabled=0
and
2: Had "keep cache=1" in /etc/yum.conf
My2¢ worth for what it's worth.
Nigel.
Nigel Henry wrote:
I use Apt, not Yum, and personally think that this default behaviour of Yum is potentially risky.
For example. You have a kernel installed when you installed FC6, and this works ok. You do a yum update, and a newer kernel is installed. For some reason this kernel does not work. Some time later after another yum update, another kernel update is installed, which removes your original kernel. If the latest kernel doesn't work, you are stuffed, as your original kernel, which did work has been removed by yum.
If you are running the kernel that works that won't be removed by this plugin. If lot of kernels don't work the problems lie elsewhere.
Personally I'm glad that I use Apt. I don't have to suffer this Yum stuff.
1: Apt keeps all kernels. You decide which ones you want to remove.
2: Yum trashes all the downloaded files as default, once the update is completed. Apt saves them as default in /var/cache/apt/archives. If you are getting a bit close to critical on harddrive space , and don't need the archives, you can do an apt-get clean, and it will send them to the trash, but at least you are in control.
Note that both of these are just a matter of default preferences and can be easily changed. The large majority of end users don't use dialup and have no requirement to save installed packages on the cache.
Rahul
On 5/6/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Nigel Henry wrote:
I use Apt, not Yum, and personally think that this default behaviour of Yum is potentially risky.
For example. You have a kernel installed when you installed FC6, and this works ok. You do a yum update, and a newer kernel is installed. For some reason this kernel does not work. Some time later after another yum update, another kernel update is installed, which removes your original kernel. If the latest kernel doesn't work, you are stuffed, as your original kernel, which did work has been removed by yum.
If you are running the kernel that works that won't be removed by this plugin. If lot of kernels don't work the problems lie elsewhere.
Personally I'm glad that I use Apt. I don't have to suffer this Yum stuff.
1: Apt keeps all kernels. You decide which ones you want to remove.
2: Yum trashes all the downloaded files as default, once the update is completed. Apt saves them as default in /var/cache/apt/archives. If you are getting a bit close to critical on harddrive space , and don't need the archives, you can do an apt-get clean, and it will send them to the trash, but at least you are in control.
Note that both of these are just a matter of default preferences and can be easily changed. The large majority of end users don't use dialup and
How do you know a user is not using dialup? More than half of my LUG is on dialup and I'm in the middle of Silicon Valley!
have no requirement to save installed packages on the cache.
Rahul
The "installonlyn" plugin is probably better suited to RHEL, not Fedora Core. I do not have a RHEL license but my take is that RHEL has fewer released kernel updates than a developmental product such as Fedora Core. If the goal of Fedora Core is to test various packages it really makes no sense for the testers (that's the entire FC user base) to have stable or reference kernel packages pulled out from them.
Kam Leo wrote: \
How do you know a user is not using dialup? More than half of my LUG is on dialup and I'm in the middle of Silicon Valley!
Reasonable guesstimate considering the number of updates that get through the server. I would say for dial ups Fedora hasn't been a good fit previously.
There are two things that are changing that.
* yum-utils got a yum security plugin which would download updates classified as security issues.
* yum presto plugin which downloads delta rpms instead of full updates. These aren't mirror widely yet but should happen sooner or later.
The "installonlyn" plugin is probably better suited to RHEL, not Fedora Core. I do not have a RHEL license but my take is that RHEL has fewer released kernel updates than a developmental product such as Fedora Core. If the goal of Fedora Core is to test various packages it really makes no sense for the testers (that's the entire FC user base) to have stable or reference kernel packages pulled out from them.
Yes it doesn't make sense if your assumptions are true but then they are not. The goals of Fedora are clearly outlined in http://fedoraproject.org/wiki/Objectives. It doesn't make much sense for RHEL and RHEL does not have it because the number of updates are very low and a plugin to manage the number wouldn't be very useful. Yum does prompt for all actions by default and all the plugins have on load messages so there is no chance that something is going to happen without the user being informed.
When you buy RHEL what you get is a subscription (which is essentially a support contract) btw, not a license
Rahul
On 5/6/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote: \
How do you know a user is not using dialup? More than half of my LUG is on dialup and I'm in the middle of Silicon Valley!
Reasonable guesstimate considering the number of updates that get through the server. I would say for dial ups Fedora hasn't been a good fit previously.
The Red Hat servers are not seeing the traffic because many are using local mirrors.
There are two things that are changing that.
- yum-utils got a yum security plugin which would download updates
classified as security issues.
- yum presto plugin which downloads delta rpms instead of full updates.
These aren't mirror widely yet but should happen sooner or later.
The "installonlyn" plugin is probably better suited to RHEL, not Fedora Core. I do not have a RHEL license but my take is that RHEL has fewer released kernel updates than a developmental product such as Fedora Core. If the goal of Fedora Core is to test various packages it really makes no sense for the testers (that's the entire FC user base) to have stable or reference kernel packages pulled out from them.
Yes it doesn't make sense if your assumptions are true but then they are not. The goals of Fedora are clearly outlined in http://fedoraproject.org/wiki/Objectives. It doesn't make much sense for RHEL and RHEL does not have it because the number of updates are very low and a plugin to manage the number wouldn't be very useful.
The life time of a Fedora release is short. Previous FC releases had less than 10 kernel updates. The number is probably on the same scale as a RHEL release over a longer period of time.
Since reaching 2.6.18 the number and velocity of kernel changes reaching the user base is greater. Why?
Yum does prompt for all actions by default and all the plugins have on load messages so there is no chance that something is going to happen without the user being informed.
Only if a user is running yum from the commandline. Some users automate updates.
When you buy RHEL what you get is a subscription (which is essentially a support contract) btw, not a license
Correction noted.
Rahul
Kam Leo wrote:
The life time of a Fedora release is short. Previous FC releases had less than 10 kernel updates. The number is probably on the same scale as a RHEL release over a longer period of time.
If you notice the number of end users asking about editing grub to change the number of kernels have just about disappeared compared to the time before the plugin was introduced. That is a pretty strong indication that this plugin had the desired effect and is helpful.
RHEL tends to attract sys admins. If you buying a subscription you are probably already invested in time and resources towards a solution and hence usually more experienced.
Fedora tends to attract a lot more new users. Barrier to entry is low - zero cost, free media, retail redistribution. Latest software is appealing to desktop folks. A plugin which manages the kernels in a reasonable way is useful for this audience. Others who are more experienced can very easily tweak it or turn it off.
Since reaching 2.6.18 the number and velocity of kernel changes reaching the user base is greater. Why?
Security issues, bugs. Got to ask the kernel maintainer. Nothing relevant to this discussion really.
Only if a user is running yum from the commandline. Some users automate updates.
If you are smart enough to tweak the default behavior which is not to do automatic updates then you as smart enough to change the plugin behavior too.
Rahul
On 5/6/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
The life time of a Fedora release is short. Previous FC releases had less than 10 kernel updates. The number is probably on the same scale as a RHEL release over a longer period of time.
If you notice the number of end users asking about editing grub to change the number of kernels have just about disappeared compared to the time before the plugin was introduced. That is a pretty strong indication that this plugin had the desired effect and is helpful.
I have not noticed. Enabling hiddenmenu in grub probably played a greater part than the plugin in reducing questions regarding changing the number of kernels. Most new users would not know that they have the capability to choose kernels at boot time.
RHEL tends to attract sys admins. If you buying a subscription you are probably already invested in time and resources towards a solution and hence usually more experienced.
Fedora tends to attract a lot more new users. Barrier to entry is low - zero cost, free media, retail redistribution. Latest software is appealing to desktop folks. A plugin which manages the kernels in a reasonable way is useful for this audience. Others who are more experienced can very easily tweak it or turn it off.
Since reaching 2.6.18 the number and velocity of kernel changes reaching the user base is greater. Why?
Security issues, bugs. Got to ask the kernel maintainer. Nothing relevant to this discussion really.
Yes, it does.The base for FC6 went from 2.6.18 to 2.6.20. Bug and security fixes alone would not have necessitated the version changes that followed. What I see is that the installonlyn plugin was created to fix the side effects of Fedora Core's kernel update mechanism/policy.
Only if a user is running yum from the commandline. Some users automate updates.
If you are smart enough to tweak the default behavior which is not to do automatic updates then you as smart enough to change the plugin behavior too.
We weren't talking about me, at least I hope not, but about less knowledgeable users. I hope our mutual goal is to improve Fedora Core.
By the way, regarding ideas for improving documentation: It is highly desirable to have man pages for all released software. Yum's plugins seem to have fallen through the cracks. If the release notes are not been maintained then I would recommend that any functional/behavioral change be documented via comments in the .conf file. It shouldn't take too much effort and is better than nothing.
Rahul
On 2007-05-07, 00:54 GMT, Kam Leo wrote:
It is highly desirable to have man pages for all released software.
Sorry, you forgot to attach the patch with those manpages. Or is it somewhere in bugzilla (then you forgot to mention bug#)?
I would recommend that any functional/behavioral change be documented via comments in the .conf file. It shouldn't take too much effort and is better than nothing.
Sure, great idea (I mean it), just go ahead and file the bug with the modified .conf files as an attachment. It could very well work as a temporary workaround before manpages are created.
Best,
Matěj
Kam Leo wrote:
Yes, it does.The base for FC6 went from 2.6.18 to 2.6.20. Bug and security fixes alone would not have necessitated the version changes that followed. What I see is that the installonlyn plugin was created to fix the side effects of Fedora Core's kernel update mechanism/policy.
Security fixes are unpredictable. Bug fixes can be accumulated but you would have some unsatisfied users anyway.
We weren't talking about me, at least I hope not, but about less knowledgeable users. I hope our mutual goal is to improve Fedora Core.
Right. "You" is figurative.
By the way, regarding ideas for improving documentation: It is highly desirable to have man pages for all released software. Yum's plugins seem to have fallen through the cracks. If the release notes are not been maintained then I would recommend that any functional/behavioral change be documented via comments in the .conf file. It shouldn't take too much effort and is better than nothing.
Want to contribute?
Rahul
On 5/6/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
Yes, it does.The base for FC6 went from 2.6.18 to 2.6.20. Bug and security fixes alone would not have necessitated the version changes that followed. What I see is that the installonlyn plugin was created to fix the side effects of Fedora Core's kernel update mechanism/policy.
Security fixes are unpredictable. Bug fixes can be accumulated but you would have some unsatisfied users anyway.
We weren't talking about me, at least I hope not, but about less knowledgeable users. I hope our mutual goal is to improve Fedora Core.
Right. "You" is figurative.
By the way, regarding ideas for improving documentation: It is highly desirable to have man pages for all released software. Yum's plugins seem to have fallen through the cracks. If the release notes are not been maintained then I would recommend that any functional/behavioral change be documented via comments in the .conf file. It shouldn't take too much effort and is better than nothing.
Want to contribute?
Have been:
1. bug reports 2. participate in this list.
Rahul
Kam Leo wrote:
On 5/6/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Want to contribute?
Have been:
- bug reports
- participate in this list.
I specifically meant for the man pages. You said it shouldn't take too much effort.
Rahul
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
On 5/6/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Want to contribute?
Have been:
- bug reports
- participate in this list.
I specifically meant for the man pages. You said it shouldn't take too much effort.
I was referring to adding comments to the .conf file for the yum plugins. That is no more difficult than adding comments to source code.
You stated the documented and actual behavior for the installonlyn plugin changed and that it was too difficult or not worth the effort to modify the FC5 release-notes. Ergo, my recommendation, document the change in installyonlyn.conf. It is the fastest way to disseminate the change. Commandline help would work, too, but it appears that yum does not provide hooks to extend help.
Rahul
Kam Leo wrote:
You stated the documented and actual behavior for the installonlyn plugin changed and that it was too difficult or not worth the effort to modify the FC5 release-notes. Ergo, my recommendation, document the change in installyonlyn.conf.
File a RFE.
It is the fastest way to disseminate
the change. Commandline help would work, too, but it appears that yum does not provide hooks to extend help.
I don't know where you got that impression but it does.
Rahul
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
You stated the documented and actual behavior for the installonlyn plugin changed and that it was too difficult or not worth the effort to modify the FC5 release-notes. Ergo, my recommendation, document the change in installyonlyn.conf.
File a RFE.
Pointless and totally ineffective. I cannot change developer habits. Those who care about their code will document.
Besides, Fedora Core is totally schedule driven. Documentation bugs are considered critical and do not hold a release. Using FC5 release notes as an example. Under the heading "Latest Release Notes on the Web", http://docs.fedoraproject.org/release-notes/fc5/ , it states "These release notes may be updated." Truth is it does not happen. Not for a free product with a 18 month life span.
It is the fastest way to disseminate
the change. Commandline help would work, too, but it appears that yum does not provide hooks to extend help.
I don't know where you got that impression but it does.
If a hook is available then why wouldn't/shouldn't options for installonlyn appear? Here's what appears:
# yum --help Loading "installonlyn" plugin usage: yum [options] < grouplist, localinstall, groupinfo, localupdate, resolvedep, erase, deplist, groupremove, makecache, upgrade, provides, shell, install, whatprovides, groupinstall, update, groupupdate, info, search, check-update, list, remove, clean, grouperase >
options: -h, --help show this help message and exit -t, --tolerant be tolerant of errors -C run entirely from cache, don't update cache -c [config file] config file location -R [minutes] maximum command wait time -d [debug level] debugging output level -e [error level] error output level -y answer yes for all questions --version show Yum version and exit --installroot=[path] set install root --enablerepo=[repo] enable one or more repositories (wildcards allowed) --disablerepo=[repo] disable one or more repositories (wildcards allowed) -x [package], --exclude=[package] exclude package(s) by name or glob --obsoletes enable obsoletes processing during updates --noplugins disable Yum plugins
With the exception of enabling or disabling all plugins the plugins are totally isolated from yum.
Rahul
On 5/7/07, Kam Leo kam.leo@gmail.com wrote:
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
You stated the documented and actual behavior for the installonlyn plugin changed and that it was too difficult or not worth the effort to modify the FC5 release-notes. Ergo, my recommendation, document the change in installyonlyn.conf.
File a RFE.
Pointless and totally ineffective. I cannot change developer habits. Those who care about their code will document.
Besides, Fedora Core is totally schedule driven. Documentation bugs are considered critical and do not hold a release. Using FC5 release
^ Typo, "not" was omitted.
notes as an example. Under the heading "Latest Release Notes on the Web", http://docs.fedoraproject.org/release-notes/fc5/ , it states "These release notes may be updated." Truth is it does not happen. Not for a free product with a 18 month life span.
It is the fastest way to disseminate
the change. Commandline help would work, too, but it appears that yum does not provide hooks to extend help.
I don't know where you got that impression but it does.
If a hook is available then why wouldn't/shouldn't options for installonlyn appear? Here's what appears:
# yum --help Loading "installonlyn" plugin usage: yum [options] < grouplist, localinstall, groupinfo, localupdate, resolvedep, erase, deplist, groupremove, makecache, upgrade, provides, shell, install, whatprovides, groupinstall, update, groupupdate, info, search, check-update, list, remove, clean, grouperase >
options: -h, --help show this help message and exit -t, --tolerant be tolerant of errors -C run entirely from cache, don't update cache -c [config file] config file location -R [minutes] maximum command wait time -d [debug level] debugging output level -e [error level] error output level -y answer yes for all questions --version show Yum version and exit --installroot=[path] set install root --enablerepo=[repo] enable one or more repositories (wildcards allowed) --disablerepo=[repo] disable one or more repositories (wildcards allowed) -x [package], --exclude=[package] exclude package(s) by name or glob --obsoletes enable obsoletes processing during updates --noplugins disable Yum plugins
With the exception of enabling or disabling all plugins the plugins are totally isolated from yum.
Rahul
Kam Leo wrote:
Pointless and totally ineffective. I cannot change developer habits. Those who care about their code will document.
You are being judgmental even before making any attempts. It is more about effective feedback rather than habits. If you are not willing to contribute that's fine.
Besides, Fedora Core is totally schedule driven.
Incorrect. Read http://fedoraproject.org/wiki/Objectives. We don't have a strict release schedule and have made several delays before. Even in Fedora 7 for example the schedule was changed and a new test release was added before some features like the merge was considered a release blocker. In a completely time based release structure like GNOME for example no feature would block the schedule.
Documentation bugs
are considered critical and do not hold a release.
Depends on the nature of documentation. We consider things like release notes fairly critical. Usually documentation wouldn't hold up a release though.
Using FC5 release
notes as an example. Under the heading "Latest Release Notes on the Web", http://docs.fedoraproject.org/release-notes/fc5/ , it states "These release notes may be updated." Truth is it does not happen. Not for a free product with a 18 month life span.
Incorrect. We have provided erratas before and will continue to do in Fedora 7 too. I have made several changes in them after the translation freeze for the ISO images in Fedora 7 and they would published in sync with the release. See http://docs.fedoraproject.org/release-notes/. There are ISO versions and erratas available.
In the last release, the release notes were separated from the fedora-release package to enable us to push documentation updates.
If a hook is available then why wouldn't/shouldn't options for installonlyn appear?
If the plugin uses those hooks, yes.
Rahul
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
Pointless and totally ineffective. I cannot change developer habits. Those who care about their code will document.
You are being judgmental even before making any attempts. It is more about effective feedback rather than habits.
No, that's a lesson learned from many years of SQA. Only those with the power of rejection can enforce coding/documentation standards.
Kam Leo wrote:
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
Pointless and totally ineffective. I cannot change developer habits. Those who care about their code will document.
You are being judgmental even before making any attempts. It is more about effective feedback rather than habits.
No, that's a lesson learned from many years of SQA. Only those with the power of rejection can enforce coding/documentation standards.
You _do not_ know that a RFE would be rejected. You are merely assuming that. That has nothing to do with standards.
Rahul
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
Pointless and totally ineffective. I cannot change developer habits. Those who care about their code will document.
You are being judgmental even before making any attempts. It is more about effective feedback rather than habits.
No, that's a lesson learned from many years of SQA. Only those with the power of rejection can enforce coding/documentation standards.
You _do not_ know that a RFE would be rejected. You are merely assuming that.
True. However, the track record for my submitted RFEs leads me to that conclusion. Getting "Not a bug" or "Won't fix" as the only feedback would discourage most people from such foolish pursuits.
That has nothing to do with standards.
Yes, it does. If some one want to contribute code to the Linux kernel they have to follow a coding standard. A standard (one probably exits) can be applied to code developed within Fedora Core. Lack of or weak enforcement is the biggest headache.
Rahul
Kam Leo wrote:
True. However, the track record for my submitted RFEs leads me to that conclusion. Getting "Not a bug" or "Won't fix" as the only feedback would discourage most people from such foolish pursuits.
Enhancements are decided on a case by case basis. Sweeping generalizations are almost always mistaken.
Yes, it does. If some one want to contribute code to the Linux kernel they have to follow a coding standard. A standard (one probably exits) can be applied to code developed within Fedora Core. Lack of or weak enforcement is the biggest headache.
Code developed within Fedora is very trivial compared to the amount of software in the distribution. The large majority of code in inherited from upstream projects and flows back into it. A standard for code or enforcement of such within Fedora makes a negligible difference to the end user experience unlike the kernel. Your assumption on that is incorrect.
Upstream projects are primary about new development. You are not comparing apples to apples if you compare the Linux kernel to Fedora.
A distribution is primarily about integration and we have large number of guidelines and policies within Fedora for that and they are extended quite often.
Rahul
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
True. However, the track record for my submitted RFEs leads me to that conclusion. Getting "Not a bug" or "Won't fix" as the only feedback would discourage most people from such foolish pursuits.
Enhancements are decided on a case by case basis. Sweeping generalizations are almost always mistaken.
For me the submission of an RFE is a roll of the dice. In a few instances, very few, the developer takes the time to discuss why the RFE is rejected. The typical
Yes, it does. If some one want to contribute code to the Linux kernel they have to follow a coding standard. A standard (one probably exits) can be applied to code developed within Fedora Core. Lack of or weak enforcement is the biggest headache.
Code developed within Fedora is very trivial compared to the amount of software in the distribution.
In quantity, yes. Quality???
The large majority of code in inherited from upstream projects and flows back into it. A standard for code or enforcement of such within Fedora makes a negligible difference to the end user experience unlike the kernel. Your assumption on that is incorrect.
Not so. A piece of code developed within Fedora Core impacted the end user experience. If there had not been any impact we wouldn't be having this discussion.
Rahul
On 5/7/07, Kam Leo kam.leo@gmail.com wrote:
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
True. However, the track record for my submitted RFEs leads me to that conclusion. Getting "Not a bug" or "Won't fix" as the only feedback would discourage most people from such foolish pursuits.
Enhancements are decided on a case by case basis. Sweeping generalizations are almost always mistaken.
For me the submission of an RFE is a roll of the dice. In a few instances, very few, the developer takes the time to discuss why the RFE is rejected. The typical
Oops hit the wrong key. Completing the thought: The typical response (generalization) for an RFE is no response.
Yes, it does. If some one want to contribute code to the Linux kernel they have to follow a coding standard. A standard (one probably exits) can be applied to code developed within Fedora Core. Lack of or weak enforcement is the biggest headache.
Code developed within Fedora is very trivial compared to the amount of software in the distribution.
In quantity, yes. Quality???
The large majority of code in inherited from upstream projects and flows back into it. A standard for code or enforcement of such within Fedora makes a negligible difference to the end user experience unlike the kernel. Your assumption on that is incorrect.
Not so. A piece of code developed within Fedora Core impacted the end user experience. If there had not been any impact we wouldn't be having this discussion.
Rahul
Kam Leo wrote:
For me the submission of an RFE is a roll of the dice. In a few instances, very few, the developer takes the time to discuss why the RFE is rejected. The typical
This sentence seems unfinished. If someone doesn't take the time to explain the first time, ask. Bugs can be reopened by the submitter or anyone else with appropriate access.
Code developed within Fedora is very trivial compared to the amount of software in the distribution.
In quantity, yes. Quality???
What about quality? Trivial is not a meaningful qualifier for it.
Not so. A piece of code developed within Fedora Core impacted the end user experience. If there had not been any impact we wouldn't be having this discussion.
This plugin was developed as part of upstream yum and inherited as default. There is nothing Fedora specific about it. If you want to look at something more closer to Fedora there are tools like pungi or the live cd tools.
Rahul
On 5/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
This plugin was developed as part of upstream yum and inherited as default. There is nothing Fedora specific about it. If you want to look at something more closer to Fedora there are tools like pungi or the live cd tools.
When code gets inserted into a Fedora Core distribution it is no longer upstream.
The installonlyn plugin is meant to fix a perceived yum user problem. I may have used too broad a brush by linking the Red Hat employee who wrote this code with Fedora Core.
Rahul
Kam Leo wrote:
When code gets inserted into a Fedora Core distribution it is no longer upstream.
That's a strange definition unless you meant it is not just upstream which then is just a general observation not very relevant to the discussion.
When downstream distributions inherit code upstream project still have it and will continue to evolve. In Fedora we try and stay in sync however there are other reasons why some distributions prefer to backport more or fork on occasions.
At any rate, the point is that a coding standard on Fedora specific code that does not go upstream which is a very small amount wouldn't make much of a difference on the overall quality of the distribution.
The installonlyn plugin is meant to fix a perceived yum user problem.
It is not really tied to the package manager but the policy on updates.
I may have used too broad a brush by linking the Red Hat employee who wrote this code with Fedora Core.
Right. It is Fedora now. Core and Extras are no more.
Rahul
Rahul Sundaram wrote:
- yum presto plugin which downloads delta rpms instead of full updates.
These aren't mirror widely yet but should happen sooner or later.
I found presto yesterday, but didn't fully understand what it was for. Could you give an example of how it works?
Martin Marques wrote:
Rahul Sundaram wrote:
- yum presto plugin which downloads delta rpms instead of full
updates. These aren't mirror widely yet but should happen sooner or later.
I found presto yesterday, but didn't fully understand what it was for. Could you give an example of how it works?
Sure
How it works -------------
Yum Presto plugin uses deltarpms aka drpms which are binary diff's between updates and the original version. So if for example Openoffice.org gets a update that changes 3 files the delta rpms would contain that instead of the full update which is essentially a complete new installation of the package with the configuration files preserved from the older version.
More details at http://fedoraproject.org/wiki/YumDeltaRPM
Using it ---------
# yum install yum-presto (plugin is in Fedora Extras)
Edit /etc/yum/pluginconf.d/presto.conf and enable the repositories. Do not enable development unless you are using the test/development version of Fedora. Core and Extras repositories are available in the configuration file and commented out.
Livna is also available at http://www.lesbg.com/jdieter/
Run
# yum update
You should be able to see presto plugin being loaded and delta rpms being downloaded instead of the full updates along with whatever size savings that gets you post installation.
Rahul
Nigel Henry wrote:
Yum by default only keeps 2 kernels. If you go to /etc/yum, and I'm running FC2 at the moment so can't check, but in /etc/yum IIRC there are 2 directories. One has to do with plugins. You want the installonlyn plugin. In this one change the line "enable=1" to "enable=0". Now all your kernels will be saved, and if you want to remove specific kernels you can do it using yumex.
I use Apt, not Yum, and personally think that this default behaviour of Yum is potentially risky.
For example. You have a kernel installed when you installed FC6, and this works ok. You do a yum update, and a newer kernel is installed. For some reason this kernel does not work. Some time later after another yum update, another kernel update is installed, which removes your original kernel. If the latest kernel doesn't work, you are stuffed, as your original kernel, which did work has been removed by yum.
This is only a problem if you do a yum update while booted the non-working kernel. I have a desktop that does not get rebooted too often, so I have had newer kernels then the one I an running removed by yum, and the older, running kernel left alone. I am trying to picture how you could end up with a kernel that works well enough that you can use yum to update the kernel, but is broken enough that you can not install a fully functional kernel... I guess you could manage it if you worked at it. I remember when you could remove the current kernel doing an rpm -Uvh <kernel RPM> instead of doing rpm -Ivh <kernel RPM>. All of a sudden, you didn't have any modules for the current kernel, so if you needed module that wasn't loaded, you were stuck. :(
For my use, I feel that the default of the currently running kernel and a new one is not enough, but I guess it works for most people.
Mikkel
Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686 0:2.6.18-1.2798.fc6 Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
For what it's worth my system at /etc/yum/pluginconf.d/installonlyn.conf is "tokeep=4" but the last kernel update only left 2 kernels in boot.I have no idea how to fix this.
david
On 5/6/07, david walcroft david_walcroft@yahoo.com.au wrote:
Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686 0:2.6.18-1.2798.fc6 Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
For what it's worth my system at /etc/yum/pluginconf.d/installonlyn.conf is "tokeep=4" but the last kernel update only left 2 kernels in boot.I have no idea how to fix this.
If you still have the packages for the removed kernels "rpm -ivh kernel-2.6.xxx." as either the superuser or root will reinstall them. If you don't have the packages locating them will be a hassle since FC mirrors keep only the latest two. (A request to the list might work.) If you do not want this problem to reoccur edit installonlyn.conf and disable the plugin.
In any event you should file a bug report.
david
On Sun, 2007-05-06 at 20:02 -0800, Kam Leo wrote:
On 5/6/07, david walcroft david_walcroft@yahoo.com.au wrote:
Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686 0:2.6.18-1.2798.fc6 Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
For what it's worth my system at /etc/yum/pluginconf.d/installonlyn.conf is "tokeep=4" but the last kernel update only left 2 kernels in boot.I have no idea how to fix this.
If you still have the packages for the removed kernels "rpm -ivh kernel-2.6.xxx." as either the superuser or root will reinstall them. If you don't have the packages locating them will be a hassle since FC mirrors keep only the latest two. (A request to the list might work.) If you do not want this problem to reoccur edit installonlyn.conf and disable the plugin.
In any event you should file a bug report.
Something I have not seen in the discussions here about "keeping old kernels" is that there have been cases where an upgrade of some "other package" has a "requires" of a certain level of kernel, and the existence of a previous kernel has prevented it's installation. Trying to remember the specific occurrences, but didn't udev do that a couple of times. But, consequently, there are other reasons to keep the number of installed kernels fewer rather than greater....
--Rob
Kam Leo wrote:
On 5/6/07, david walcroft david_walcroft@yahoo.com.au wrote:
Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686
0:2.6.18-1.2798.fc6
Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
For what it's worth my system at /etc/yum/pluginconf.d/installonlyn.conf is "tokeep=4" but the last kernel update only left 2 kernels in boot.I have no idea how to fix this.
If you still have the packages for the removed kernels "rpm -ivh kernel-2.6.xxx." as either the superuser or root will reinstall them. If you don't have the packages locating them will be a hassle since FC mirrors keep only the latest two. (A request to the list might work.) If you do not want this problem to reoccur edit installonlyn.conf and disable the plugin.
In any event you should file a bug report.
david
I tried that,this is the result.
[david@reddwarf ~]$ sudo rpm -qa | grep kernel kernel-2.6.19-1.2911.fc6.i686 kernel-2.6.20-1.2933.fc6.i686 kernel-2.6.20-1.2948.fc6.i686 kernel-2.6.20-1.2944.fc6.i686 [david@reddwarf ~]$ sudo rpm -ivh rpm: no packages given for install [david@reddwarf ~]$ sudo rpm -ivh kernel-2.6.19-1.2911.fc6.i686 kernel-2.6.20-1.2933.fc6.i686 error: open of kernel-2.6.19-1.2911.fc6.i686 failed: No such file or directory error: open of kernel-2.6.20-1.2933.fc6.i686 failed: No such file or directory
thanks david
On Tue, 2007-05-08 at 09:55 +1000, david walcroft wrote:
Kam Leo wrote:
On 5/6/07, david walcroft david_walcroft@yahoo.com.au wrote:
Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686
0:2.6.18-1.2798.fc6
Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
For what it's worth my system at /etc/yum/pluginconf.d/installonlyn.conf is "tokeep=4" but the last kernel update only left 2 kernels in boot.I have no idea how to fix this.
If you still have the packages for the removed kernels "rpm -ivh kernel-2.6.xxx." as either the superuser or root will reinstall them. If you don't have the packages locating them will be a hassle since FC mirrors keep only the latest two. (A request to the list might work.) If you do not want this problem to reoccur edit installonlyn.conf and disable the plugin.
In any event you should file a bug report.
david
I tried that,this is the result.
[david@reddwarf ~]$ sudo rpm -qa | grep kernel kernel-2.6.19-1.2911.fc6.i686 kernel-2.6.20-1.2933.fc6.i686 kernel-2.6.20-1.2948.fc6.i686 kernel-2.6.20-1.2944.fc6.i686 [david@reddwarf ~]$ sudo rpm -ivh rpm: no packages given for install [david@reddwarf ~]$ sudo rpm -ivh kernel-2.6.19-1.2911.fc6.i686 kernel-2.6.20-1.2933.fc6.i686 error: open of kernel-2.6.19-1.2911.fc6.i686 failed: No such file or directory error: open of kernel-2.6.20-1.2933.fc6.i686 failed: No such file or directory
Uh, you have to provide the path to the RPM file for "rpm -ivh" to work:
rpm -ivh /path/to/kernel-2.6.19-1.2911.fc6.i686.rpm
And even then it may not install because you have later kernels installed. You may have to use a "--force" (and that can be dangerous).
---------------------------------------------------------------------- - Rick Stevens, Principal Engineer rstevens@internap.com - - VitalStream, Inc. http://www.vitalstream.com - - - - If at first you don't succeed, quit. No sense being a damned fool! - ----------------------------------------------------------------------
On 5/7/07, david walcroft david_walcroft@yahoo.com.au wrote:
Kam Leo wrote:
On 5/6/07, david walcroft david_walcroft@yahoo.com.au wrote:
Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686
0:2.6.18-1.2798.fc6
Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new ones and leave old ones there?
For what it's worth my system at /etc/yum/pluginconf.d/installonlyn.conf is "tokeep=4" but the last kernel update only left 2 kernels in boot.I have no idea how to fix this.
If you still have the packages for the removed kernels "rpm -ivh kernel-2.6.xxx." as either the superuser or root will reinstall them. If you don't have the packages locating them will be a hassle since FC mirrors keep only the latest two. (A request to the list might work.) If you do not want this problem to reoccur edit installonlyn.conf and disable the plugin.
In any event you should file a bug report.
david
I tried that,this is the result.
[david@reddwarf ~]$ sudo rpm -qa | grep kernel kernel-2.6.19-1.2911.fc6.i686 kernel-2.6.20-1.2933.fc6.i686 kernel-2.6.20-1.2948.fc6.i686 kernel-2.6.20-1.2944.fc6.i686 [david@reddwarf ~]$ sudo rpm -ivh rpm: no packages given for install [david@reddwarf ~]$ sudo rpm -ivh kernel-2.6.19-1.2911.fc6.i686 kernel-2.6.20-1.2933.fc6.i686 error: open of kernel-2.6.19-1.2911.fc6.i686 failed: No such file or directory error: open of kernel-2.6.20-1.2933.fc6.i686 failed: No such file or directory
thanks david
"rpm -qa | grep" did the following:
1) Instructed rpm to query the rpm database for all installed packages. 2) Piped the query out to grep 3) Instructed grep to search its input stream for the string "kernel" 4) Four matching strings were found
You have four kernels installed in your system.
If you want to see the four kernels appear in the grub boot menu you can a) press the space bar or b) edit /boot/grub/menu.lst and place the "#" symbol in front of "hiddenmenu" to disable the feature.
"[david@reddwarf ~]$ sudo rpm -ivh kernel-2.6.19-1.2911.fc6.i686" has no effect because you do not have a file named kernel-2.6.19-1.2911.fc6.i686 in the current working directory (/home/david).
On Sun, 2007-05-06 at 17:16 -0300, Martin Marques wrote:
I just finished upgrading the kernels in my FC6 with yum and I see this at the end:
Removed: kernel.i686 0:2.6.20-1.2933.fc6 kernel.i686 0:2.6.18-1.2798.fc6 Installed: kernel.i686 0:2.6.20-1.2948.fc6
Now, why did it remove does kernel? Shouldn't it just install the new
I can't remeber if I answered you or not. The nuber of kernels retained is controlled by the: /etc/yum/pluginconf.d/installonlyn.conf file. -- ======================================================================= An INK-LING? Sure -- TAKE one!! Did you BUY any COMMUNIST UNIFORMS?? ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
-
Aaron Konstam -
david walcroft -
James Wilkinson -
Kam Leo -
Martin Marques -
Matej Cepl -
Mikkel -
Nigel Henry -
Rahul Sundaram -
Rick Stevens -
Robert Locke