On Friday 18 January 2008 21:58, Michael Schwendt wrote: > On 18/01/2008, Nigel Henry <cave.dnb@xxxxxxxxxx> wrote: > > On Friday 18 January 2008 04:15, Michael Schwendt wrote: > > > On 18/01/2008, Nigel Henry <cave.dnb@xxxxxxxxxx> wrote: > > > > Now I comment out freshrpms, and uncomment the livna repo. > > > > > > I've shown just recently that the x264 package from livna is seen as > > > "older than" the package from freshrpms despite offering a newer > > > snapshot of the library. In other words, the older software > > > libx264.so.55 will upgrade the newer software libx264.so.56 due to how > > > the packages are versioned. And of course the change in the library > > > version additionally breaks package dependencies: > > > > > > $ rpmdev-vercmp 0 0.0.0 0.3.20070529.fc7 0 0 0.10.20070819.lvn8 > > > 0:0.0.0-0.3.20070529.fc7 is newer > > > > > > That translates to > > > > > > Epoch: 0 > > > Version: 0.0.0 > > > Release: 0.3.20070529.fc7 > > > > > > compared with > > > > > > Epoch: 0 > > > Version: 0 > > > Release: 0.10.20070819.lvn8 > > > > > > and is like that because "0.0.0" is higher than "0" in RPM version > > > comparison. Even if both packages used "Version: 0", it would be > > > necessary to agree on a common "Release" scheme as the date of the > > > software here is very important. Alternatively, creating a separate > > > namespace for every library major version would have worked, too. > > > > Apologies Michael. I do remember you having discussed x264 on a previous > > post. > > > > I don't have a test install of F8 at the moment, but as a workaround for > > the x264 package problem, would this sort of thing (as below) work? > > > > Download x264 rpm from Livna, then install it using "rpm -Uvh > > --oldpackage <path to livna x264 package>" > > RPM would refuse to do that if any installed package requires the > library from the freshrpms' x264 package. If any of the installed > packages requires libx264.so.55 from the freshrpms pkg, you cannot > downgrade the x264 package to livna's version because it only contains > the newer libx264.so.56 library. :) Thanks for clarifying that Michael. It makes the point that playing mix and match with 3rd party repo's doesn't work, and any perceived workarounds are unlikely to work. Thanks again for your reply. Nigel.
