Currently in rawhide at the moment yum treats kernel-devel as installonly but kernel-smp-devel package is treated as a normal package when doing updates.
Which is the more correct befault behavior? Do we want multiple versions of kernel-devel and kernel-smp-devel packages to be installed by default or do we want these packages to update?
If we want multiple versions to install, as default behavior, do we want to use a different mechanism then the package name? Like using a common provides statement that yum can see and act on.. similar to how kernel and kernel-module packages are sensed?
-jef
Jeff Spaleta wrote:
Currently in rawhide at the moment yum treats kernel-devel as installonly but kernel-smp-devel package is treated as a normal package when doing updates.
Which is the more correct befault behavior? Do we want multiple versions of kernel-devel and kernel-smp-devel packages to be installed by default or do we want these packages to update?
We need the ability to install any or multiple kernel-*devel packages in order to build modules against any target kernel version and arch. Upgrade is never desired with kernel-*devel.
If we want multiple versions to install, as default behavior, do we want to use a different mechanism then the package name? Like using a common provides statement that yum can see and act on.. similar to how kernel and kernel-module packages are sensed?
Yes. Modifying a list of names in yum is bad. The packages themselves should tell the dep resolver "Do not upgrade me!"
Warren Togami wtogami@redhat.com
On Mar 27, 2005, Warren Togami wtogami@redhat.com wrote:
We need the ability to install any or multiple kernel-*devel packages in order to build modules against any target kernel version and arch. Upgrade is never desired with kernel-*devel.
I disagree. Having to clean up for up2date/yum/whatever because multiple kernels pile up as updates are released is already bad enough, but it's desirable because, if you removed the old kernel and the new one happened to break on your box, you're toast.
I can't think of any such strong rationale for kernel*-devel. Sure, it may be convenient for a small fraction of the developer base, which is significantly smaller than the user base. IMHO kernel*-devel should upgrade just like any other package. The few people who would rather keep multiple kernel-devel packages are probably skilled enough to make the small configuration change needed to achieve their goal.
wtogami@redhat.com (Warren Togami) writes:
Currently in rawhide at the moment yum treats kernel-devel as installonly but kernel-smp-devel package is treated as a normal package when doing updates. Which is the more correct befault behavior? Do we want multiple versions of kernel-devel and kernel-smp-devel packages to be installed by default or do we want these packages to update?
We need the ability to install any or multiple kernel-*devel packages in order to build modules against any target kernel version and arch. Upgrade is never desired with kernel-*devel.
Never say 'never'... Although 'install' will be the right choice for a lot of systems, there are other ones where 'upgrade' is desired (not only for 'kernel*devel', but for 'kernel' also). E.g. for vservers it does not make much sense to install a second kernel.
If we want multiple versions to install, as default behavior, do we want to use a different mechanism then the package name? Like using a common provides statement that yum can see and act on.. similar to how kernel and kernel-module packages are sensed?
Yes. Modifying a list of names in yum is bad. The packages themselves should tell the dep resolver "Do not upgrade me!"
Whichever solution will be applied, adding yet more black magic to the depsolver (which can not be overridden) must be prevented.
Enrico
Enrico Scholz wrote:
Never say 'never'... Although 'install' will be the right choice for a lot of systems, there are other ones where 'upgrade' is desired (not only for 'kernel*devel', but for 'kernel' also). E.g. for vservers it does not make much sense to install a second kernel.
For corner cases like vservers or buildroots, we should have a kernel-999 fake package. It wont ever change. Simple.
Warren Togami wtogami@redhat.com
wtogami@redhat.com (Warren Togami) writes:
Never say 'never'... Although 'install' will be the right choice for a lot of systems, there are other ones where 'upgrade' is desired (not only for 'kernel*devel', but for 'kernel' also). E.g. for vservers it does not make much sense to install a second kernel.
For corner cases like vservers or buildroots, we should have a kernel-999 fake package.
It will give only trouble... you will need yet more special magic in the depsolver to differ between the regular kernel packages and faked ones. A simple and better solution would be the removal of any exception (e.g. implicit and unoverridable 'installonlypkg' for 'kernel') or other automatism (e.g. guessing of repo- or cachedir) in the depsolver. Such paternalism will strike back -- at least with vservers or buildroots.
Instead of, provide reasonable defaults (e.g. write 'installonlypkg = kernel' in the shipped yum.conf) which can be overridden by the user.
It wont ever change. Simple.
What is, when next xorg-x11 requires kernel-drm >= 4.4.0?
Enrico
packaging@lists.fedoraproject.org
-
Alexandre Oliva -
Enrico Scholz -
Jef Spaleta -
Warren Togami