kernel-devel: should yum install, not update?

Jeff Johnson n3npq at nc.rr.com
Tue Jan 25 00:39:07 UTC 2005


Axel Thimm wrote:

>On Mon, Jan 24, 2005 at 07:19:11PM -0500, Jeff Johnson wrote:
>  
>
>>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,
>>    
>>
>
>Of course it is. It is the packager's decision whether he will craft a
>package that will allow concurrent non-conflicting installs of the
>same package in different versions. This is currently (only) true for
>the kernel packages, but could easily be extended to gcc and python
>packages.
>
>So if the packager has taken care to allow for concurrent installs he
>will tag his package appropriately.
>
>A higher level resolver has otherwise no chance on deriving this
>information and the current patching of resolvers to allow certain
>packages to be installed instead of upgraded will have an end.
>  
>

We disagree, as we do on Disttag:.

I won't waste further time arguing the issue with you, you're mistaken.

In fact, I will probably slam dunk a pre-emptive implementation for

    AutoUpgrade: no

just as I have for Disttag: in rpm-4.4, because the implementation is easier
than wasting my breath discussing.

<shrug>

73 de Jeff


>  
>
>>and so the value needs to be dynamic, not static, configuration on
>>the install, not the build, machine.
>>    
>>
>
>No, it's packaging time that counts.
>
>I hope you change your mind and allow for a new tag in
>rpm. Alternatively it can be modelled with fake Provides instead, but
>a method on rpm level would standardize this before every distro and
>its cat uses a different provides mechanics.
>
>  
>
>>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.
>>    
>>
>
>That's a bit unrelated to this issue. The disttag is to indicate the
>build environment and to make packages build out of the same specfile
>on different build environments to align properly in rpm upgrade paths
>(same specfile, different build environments: make build environments
>of newer distros win).
>  
>





More information about the fedora-devel-list mailing list