kernel-devel: should yum install, not update?

[Jeff Johnson]

Alexandre Oliva wrote:

>On Jan 24, 2005, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
>
>  
>
>>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 why couldn't the depsolver itself verify that conflicts do not
>exist between the installed version and the to-be-installed one?  I
>think it's my turn to show that we don't need additional annotations
>:-)
>

Additional annotations for what? What problem are you trying to solve?

Depsolvers can of course do whatever they wish with the information
and mechanisms provided by rpmlib. Not that very much is being
attempted these days, debugging 1000+ package transactions ain't
exactly fun. And there is a desperate need for better install/upgrade
package policy choices. What's currently passing for state-of-the-art
is little more than arch scoring with a dash of multilib tabasco, if
you catch my drift.

FWIW, "missingok" generalizes to all dependencies, not just Requires:,
and in an equivalently semantic free (from rpmlib POV) fashion.

So "optional" annotation mark-up development is quite possible. Just
not Disttag: or Autoupdate: no, please.

And no matter what, the lack of dependeable analysis tools is the
impediment to better depsolver implemnentations.

Dry labbing dependency graph analysis is way way easier than
debugging 1000+ package transactions in situ.

73 de Jeff