List:MySQL++« Previous MessageNext Message »
From:Jack Eidsness Date:March 19 2007 3:04pm
Subject:Re: RPM packaging and library versioning
View as plain text  

Warren Young wrote:
> Remi Collet wrote:
> 
>> Patch0:     mysql++-2.2.1-bkl.patch
> 
> What is this patch?  Should I apply it to the repository?

This should go in the repository instead of an RPM-based patch, probably 
to go out as a 2.2.2.  The so_version isn't really there to fix the RPM, 
it fixes the forwards compatibility of having multiple library versions 
installed.  That's how I was looking at it - I wanted more predictable 
behavior through package management when I started this thread, but this 
doesn't help with that.  "My way" would be to have only one version of 
the lib, and consequently, the so_version stuff would be mostly 
irrelevant, assuming you have the ability to rebuild whatever you've 
been linking to mysql++.

Remi Collet wrote:
> You only have to change
>   %files
>   %{_libdir}/libmysqlpp.so.*
>   ...
> 
>   %files devel
>   %{_libdir}/libmysqlpp.so

I don't think that's what people expect for a package and it's "-devel" 
counterpart.  the .so and the .so.v.v.v serve essentially the same 
purpose, and if there needed to be a "-devel" package, it would have 
header files in /usr/include.  I don't think it's worthwhile to split 
them out.
   I haven't made time to find a decent example, but I have a vague 
memory of some packages having a "-compat" counterpart, that 
simultaneously meets my package management expectations and allows 
multiple library versions to coexist.  I would expect that "just 
mysql++.*.rpm" would have the includes (why not?) as well as the library 
in .so.v.v.v and with a .so symlink, and if you wanted to simultaneously 
have a mysql++.1.7*.rpm, you could install it as a mysql++-compat-1.7 
package, and that would just have a .so.4.0.0 and no symbolic link, and 
no .h files, or headers in some non-standard directory (not sure about 
this last part).

-Jack Eidsness
Thread
Re: RPM packaging and library versioningJack Eidsness8 Mar
  • Re: RPM packaging and library versioningWarren Young8 Mar
    • Re: RPM packaging and library versioningRemi Collet8 Mar
      • Re: RPM packaging and library versioningWarren Young16 Mar
        • Re: RPM packaging and library versioningJack Eidsness16 Mar
          • Re: RPM packaging and library versioningWarren Young17 Mar
            • Re: RPM packaging and library versioningRemi Collet18 Mar
              • Re: RPM packaging and library versioningWarren Young19 Mar
                • Re: RPM packaging and library versioningJack Eidsness19 Mar
                  • Re: RPM packaging and library versioningRemi Collet19 Mar
                    • Re: RPM packaging and library versioningJack Eidsness19 Mar
                  • Re: RPM packaging and library versioningWarren Young19 Mar
                    • Re: RPM packaging and library versioningJack Eidsness19 Mar
                • Re: RPM packaging and library versioningRemi Collet19 Mar
                  • Re: RPM packaging and library versioningWarren Young19 Mar