Re: are RPMForge and EPEL compatible?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux