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