How to update a package when version/revision is lower than the installed?

[MBantz]

Hi all,

I've packaged libx264 version 0.83 and the current in Synaptic is versioned 1.65, and thus I can't update it. Can synaptic be told to force the package?

It is possible to either force the installation or use epochs here locally.

I've built two packages, one that replaces the current x264-1.65 (with libx264-65) and the latest version of the library libx264-83. Needed to to this to make them live side-by-side.

The two srpms are in dropbox.

I tried the epoch strategy but ended up thinking that this approach is 'not nice' so I just wonder if/how the package can be dealt with. A great deal of programs depend on libx264.so.65.

I'm currently updating/repackaging the dependencies but will wait with this until I know how to handle this package.

The new packaging of x264 uses the version number as part of the rpm name, and let different versions live side-by-side.

BTW. can't compile Cinelerra, looks like the code is from 2007, is there anyone using this at all? Got a fresh version from Git - this does not compile either. Git also don't tell what revision the downloaded source is at, so annoying.

Finally, does anyone know the command to find the srpm from the name of the rpm? I can't find the srpms for these packages:
  libopal3.6.6-plugins-3.6.6-1pclos2010
  gstreamer0.10-x264-0.10.13-1pclos2010

mythTV 0.22 is ready for testing, but need this X264 sorted out,

cheers
MBantz

[AndrzejL]

to downgrade the package:

keep the newer package installed
in konsole run:

su [ENTER]
roots password [ENTER]
rpm -ivh --force /path/to/older.rpm [ENTER]
open synaptic and ok message about double package installed. Find  and remove newer package.
Use texstars howto to pin the older package so it wouldnt be updated...

Not really sure that I understood Your intentions right... so I if I didnt just ignore me...

Andy

[MBantz]

Thanks AndrzejL :-)

sorry for not explaining right:

In this situation I have a -newer- package with a -lower- version number than the current in Synaptic, and how to come by this? Easy thing would be just to push the version one up, but then the rpm version and actual program-version does now follow each other (in this situation I could rename it 1.83 but the real version is 0.83). Just to avoid confusion.

When the finished package is uploaded and added to synaptic it need to install over the old package on all systems when updating. Apt-get won't install unless the version is higher - and I assume Synaptic is using the same apt.

The current version of x264 is 1.65, the .65 refer to the library version but the 1 does not refer to anything as I can see. Other distros uses the more correct 0.65 and I've packaged it to follow the library version, and also to let the libraries live side-by-side and for easy updating of the library. FYI, 0.65 is needed by 15-20 programs and the newer 0.83 is needed for 4-5 programs,

cheers,
MBantz

[Texstar]

At one time we had 4 different versions of x264 on the system with different programs compiled against different versions which was really a nightmare to maintain. We found out that we only needed version 65 for everything to work. We bumped the number to 1.65 so it would update over all of the 4 different x264 libs and rebuilt all of the programs against one version on x264. Not really looking forward to having one version of x264 for mplayer, one for myth-tv and another for something else etc... Everytime you get ready to update a program you will have to find and replace the x264 development package just to compile that one program.

[MBantz]

Thanks for the explanation Tex,

I have packaged it so it's 'gentle' for packagers :-) The first srpm/rpm replaces the current x264 1.65 library with same library but different name: libx264-65 and the second srpm/rpm install libx264-83 (that is needed for latest ffmpeg svn) - and both libraries can co-exist side-by-side.

I have rebuilt almost all dependencies to x264 against this new naming-scheme but need to be certain I get this package installed. When all is rebuilt we can drop libx264-65.

I'm all-in for having at max two versions of one library.

BTW. it's hard to impossible to rebuild Cinelerra - really need some time to update this, so having these two libraries (libx264-65 and libx264-83) would be a welcome time-buffer for me. Avidemux, vlc, ffmpeg (upgraded), mencoder and a couple more have already been rebuilt here,

cheers,
MBantz