Alexandre Oliva wrote:
On Jan 24, 2005, Axel Thimm <Axel.Thimm@xxxxxxxxxx> 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
