Author Topic: Library naming conventions & confusions  (Read 194 times)

Offline sling-shot

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 1759
  • Satyameva Jayate | Truth Alone Triumphs.
Library naming conventions & confusions
« on: February 20, 2013, 10:35:27 AM »
I have a difficulty in following some of our package naming conventions when it comes to libraries.
Recently, I am confused about libtorrent-rasterbar.
The final built library package is named libtorrent-rasterbarn where n is the major number.
However this number is not part of the version number but is attached to the library name.
But the devel package is plainly named libtorrent-rasterbar-devel
So an upgrade of libtorrent-rasterbar will cause upgrade of the devel-package but 2 libtorrent-rasterbar packages named n and m.

Probably this is done to facilitate keeping multiple versions of the same library.

Now when a package needs libtorrent-rasterbar to build, it cannot be built with libtorrent-rasterbar but with libtorrent-rasterbarn. However if libtorrent-rasterbarn gets updated and older version removed it will cause that package fail to install because that library is lacking.

Is that the reason why we have some 3 - 4 different packages of the same library in our repository?

How should I create the .spec file for the library / package in a situation where the repo has an older version of the library but a new package needs a newer version of the same library?
Packaging well will cure headaches of many :) But learning to package will cause headaches in many :(

AMD AthlonX2 3600+/ASUS M2NPV-VM/ATi HD4670/Onboard sound/3.5GB DDR2-533 RAM/SEAGATE 160+320GB HDD/DELL S2240L FullHD/Creative SBS370 2.1/PCLinuxOS2013/KDE4
Samsung NP305U1-A06IN | Nokia E6

Offline TerryN

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 740
Re: Library naming conventions & confusions
« Reply #1 on: February 21, 2013, 09:18:57 AM »
The -devel package should represent the latest stable version  (i.e the one we are currently building against).

You are correct that the major number (the ABI version) is added to the final library name so that older versions can be kept in the repo to cater for dependent packages that haven't been rebuilt against the new ABI version (ideally they all should be rebuilt and the old library can then be removed to stop the repo getting cluttered with old versions).  Without that difference in package name apt/synaptic would remove the old library and replace it with the new during an update resulting in broken packages.  All new packages should be being built against the latest stable ABI version which is why the -devel package does not generally have the major number added to the name.

You don't need to do anything to the SPEC file.  You specify libtorrent-rasterbar-devel in the Buildrequires and that will install (currently) libtorrent-raterbar-devel-0.15.8-1 (which is for ABI version 6) which means you are building against the currently supported version.  If a package won't (or can't be patched to) build against the current version it is probably not worth having  ;)

Terry.
« Last Edit: February 21, 2013, 12:02:32 PM by TerryN »
Dell E521 - AMD 64 X2 5000+, 4GB RAM, ATI X1300 graphics
PCLinuxOS 2013 (KDE)
|Twitter|

Offline sling-shot

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 1759
  • Satyameva Jayate | Truth Alone Triumphs.
Re: Library naming conventions & confusions
« Reply #2 on: February 21, 2013, 09:37:55 AM »
Hmmm... that seems to clear things up. Or am I hallucinating ? Whooops... :)
Packaging well will cure headaches of many :) But learning to package will cause headaches in many :(

AMD AthlonX2 3600+/ASUS M2NPV-VM/ATi HD4670/Onboard sound/3.5GB DDR2-533 RAM/SEAGATE 160+320GB HDD/DELL S2240L FullHD/Creative SBS370 2.1/PCLinuxOS2013/KDE4
Samsung NP305U1-A06IN | Nokia E6

Offline gseaman

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 3892
Re: Library naming conventions & confusions
« Reply #3 on: February 21, 2013, 07:44:41 PM »
If you have to build against an older library, you can downgrade the -devel file to the one that matches the desired library version, and then build your package against it. This should be rare, though.

Galen