[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.

> 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).
-- 
Axel.Thimm at ATrpms.net

Attachment: pgp00153.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]