Axel Thimm wrote:
On Sat, Jan 22, 2005 at 10:33:05PM -0600, Michael Favia wrote:
Dave Jones wrote:
Yes but the real question is "Where does this information belong?" IOn 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.
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
