CuarzoSoftware / SRM

Simple Rendering Manager
MIT License
51 stars 5 forks source link

license info and soversion #9

Closed sudipm-mukherjee closed 8 months ago

sudipm-mukherjee commented 8 months ago

I was looking at https://bugs.debian.org/1051309 and started working on that. But I need your help with 2 points.

  1. Looks like you have recenlty chaged the license from GPL-3+ to MIT. Can you please do a v0.3.2-3 release so that I can start with the updated license information in Debian/Ubuntu.
  2. The library does not add a soversion to its soname. The spec at https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html says:

    Every shared library has a special name called the ``soname''. The soname has the prefix ``lib'', the name of the library, the phrase ``.so'', followed by a period and a version number 

    So I am adding this patch to Debian:

    diff --git a/src/meson.build b/src/meson.build
    index 7efdede..e43f7a1 100644
    --- a/src/meson.build
    +++ b/src/meson.build
    @@ -84,6 +84,7 @@ SRM = library(
         drm_dep,
         gbm_dep
     ],
    +    soversion: 0,
     install : true)
    
    pkg.generate(

    It will be great if you can have a look at these 2 points please and release a version with these.

ehopperdietzel commented 8 months ago

Hey, thank you! 😊 I'm just about to finish adding a new feature, and I plan to create a new release, probably today or tomorrow. The upcoming version will be 0.4.0-1. So, would you recommend me to set the soversion to 0 or 0.4.0-1? I took a look at some of the libs installed on my machine, and I noticed that some of them have names like libNAME.so.X.Y.Z-W. However, I'm concerned it might cause compatibility problems when linking. What's your suggestion?

sudipm-mukherjee commented 8 months ago

Please keep the soversion as 0 as your software version will still be 0.4.0. usually the major version is used as the soversion, which in your case is 0. and as you have noticed some libraries add the full version in soversion, but the process to update those package in Debian is complicated. And there is not much advantage in using the full version also.

This is what it will look like after packaging: libsrm0 will have /usr/lib/x86_64-linux-gnu/libSRM.so.0
and libsrm-dev will have all the header files, the packageconfig file and it will also have a symlink: /usr/lib/x86_64-linux-gnu/libSRM.so -> libSRM.so.0

Anyone who needs to use your library will always have to install the libsrm-dev and that will always have the correct symlink, so they will only need to use -lSRM in their makefile. When you move to a soversion of 1, the symlink will be to libSRM.so.1 so none of the user will have to change anything in their build scripts, they will only ever need -lSRM. So, whatever version you choose to use linking will not be a problem.

And the soname should never have a - in it, it can only have . so I will suggest to keep the soversion as 0 which will make it simpler in all ways.

ehopperdietzel commented 8 months ago

Okay, I understand. Thank you for the explanation. I added the 'soversion' option in 'meson.build' to ensure it always uses the major version. Here is the release:

SRM v0.4.0-1

Cheers

sudipm-mukherjee commented 8 months ago

Thanks, looks good.
Its now in the Debian new package queue waiting to be reviewed.

ehopperdietzel commented 8 months ago

Thank you so much!!

sudipm-mukherjee commented 8 months ago

@ehopperdietzel just fyi, This is now in Debian at https://tracker.debian.org/pkg/libsrm.

ehopperdietzel commented 8 months ago

Thank you very much!! I'm going to try it later on my Debian PC 😀