Re: kernel-devel: should yum install, not update?

[Jeff Johnson <n3npq nc rr com>]

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).
>