Axel Thimm wrote:
>>> Sorry, that's not possible. Just to give an example: For some reason
>>> you favour repo A and make it trump over repo B. Both repos ship
>>> libfoo and repo B ships also appbaz needing libfoo with a couple more
>>> configure options turned on.
>>>
>>> No smart package manager in the world will detect this breakage. One
>>> could strat thinking about stricter dependencies etc. but there will
>>> always be real-world scenarios like the above spoiling your master
>>> plan.
>> How much more information would rpm/yum need to store and consider in order
>> to understand that they should never overwrite a package from one
>> repository with one from a different repository without explicit
>> instructions?
>
> Les, please read the example again. It assumes that rpm/yum already
> does so (and indeed with some plugins you can do that), but shows that
> you still end up with a broken system.
I still don't understand. If I had the ablility to specify which repo
to use for libfoo and either the enhanced libfoo is backwards compatible
or I can specify that all things depending on libfoo come from repo B,
then subsequently the system knows enough not to overwrite repo B's
packages with potentially different packages from some other repo, what
will break?
> I'll just repeat myself: If the packagers don't cooperate no technical
> solution will be able to really cover compatibilty problems. You'll
> paper over some of them and create a false feeling that you have
> mastered the compatibility problem and still wonder later why it
> doesn't work. I've seen dozen of such false bug reports which I call
> "partial/selective enabling of repos". Google the last term and you
> find many bad examples of such "solutions".
You'll find examples of where things in a single repository are
incompatible with each other for certain periods of time so expecting
perfection is obviously impossible. A technical means to control what
you load won't stop you from doing something wrong but it would permit
you do it right and keep it that way across updates.
--
Les Mikesell
lesmikesell at gmail.com