kernel-devel: should yum install, not update?

Jeff Johnson n3npq at nc.rr.com
Tue Jan 25 00:19:11 UTC 2005


Axel Thimm wrote:

>On Sat, Jan 22, 2005 at 10:33:05PM -0600, Michael Favia wrote:
>  
>
>>Dave Jones wrote:
>>    
>>
>>>On Sat, Jan 22, 2005 at 03:22:53PM -0500, Jeff Spaleta wrote:
>>>
>>> > Providing 'kernel-modules' on the other hand... i don't think anything
>>> > requires 'kernel-modules' so it might be okay to make kernel-devel
>>> > provide that but i still seems to me like potential double-meaning to
>>> > what 'kernel-modules' means since kernel-devel doesnt actually include
>>> > a single kernel-module.
>>> > 
>>> > Maybe  Dave Jones can be poked into making a comment about this.
>>>
>>>Adding either of the provides seems like a rather ugly hack.
>>>up2date already has the smarts to installonly the -devel package,
>>>so I'm of the opinion yum should be fixed to do the right thing too.
>>>Jeremy is rebuilding yum as I type for tomorrows rawhide to
>>>take care of this issue.
>>>      
>>>
>>Yes but the real question is "Where does this information belong?" I
>>dont think that these things should be managed ad-hoc by each competing
>>package manager but instead internalized into the packages themselves
>>somehow for scalabiltiy and adaptability purposes.
>>    
>>
>
>It has often been suggested to add a new rpm tag for this
>purpose. E.g. you could have
>
>UpdateMode: (installation|alwaysupgrade)
>
>or
>
>AutoUpgrade: no
>
>rpm 4.4 would be a good candidate to get this in.
>  
>

Not going to happen in rpm-4.4, or in *.rpm packaging.

There is no way for the packager to determine how a package should be 
installed
on client machines, and so the value needs to be dynamic, not static, 
configuration
on the install, not the build, machine.

FWIW, the reasoning is exactly the same for no Disttag:, as the package 
may be included
in multiple distro's without rebuild, and so cannot be represented by 
static elements
in metadata.

73 de Jeff




More information about the devel mailing list