On Sun, Dec 09, 2007 at 02:09:36PM -0600, Les Mikesell wrote:
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?
You now input information that you probably only get after your system has been broken. How would you (or and other end-user) know in advance that one would need to special-treat libfoo? The typical user wouldn't even know what libs are needed for the app he/she wants to install.
And let's make the example insoluble: Now consider repo A shipping appbar which needs different build options than repo B's appbaz. Now the only thing that could save the day would be repo A and B talking.
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
Which is a very bad repo design - that's why the idioms from Debian and Madriva concerning forward/backward compatibility libs are a must and not a nice-to-have option.
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.
Perfection? No one is asking for that, but broken depsolver settings from priorities/weighing/name-it-as-you-like have cost me too much support time. It creates a per-user different invalid bug scenario which the repo managers have to untangle only to find out that appbaz was forced to work against another repo's libfoo due to per-user preferences.
Yes, per-user bugs are hideous and by design a bug in itself.