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. -- Axel.Thimm at ATrpms.net
Attachment:
pgp2vTml7hG6r.pgp
Description: PGP signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
