List:MySQL++« Previous MessageNext Message »
From:Remi Collet Date:March 19 2007 6:58pm
Subject:Re: RPM packaging and library versioning
View as plain text  
Jack Eidsness a écrit :
> This should go in the repository instead of an RPM-based patch, probably
> to go out as a 2.2.2.  

Of course. It's just a try a do some tests.
I'm not going to push this RPM. Waiting for 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++.

I don't think so.
If you build from source, you have the ability to rebuild.
If you use RPM, you don't.

RPM Dependencies are handle on the .so.# lib :

   # rpm -q --requires php-mysql | grep libmysql
   libmysqlclient.so.15()(64bit)
   libmysqlclient.so.15(libmysqlclient_15)(64bit)
   # rpm -q --whatprovides 'libmysqlclient.so.15()(64bit)'
   mysql-5.0.37-1.fc6.remi

When updating the lib (.so.#) it will break the dependency.
2 solutions :
	- compat-* is available and will be install during the update
	- compat-* not available, no update
In this way, nothing is broken.

This is a very predictable behavior, use by must of the distro.

Updating .so.#.#.# is not a problem because it is ABI compatible.

> 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, 

Don"t think.
.so.#  is used at run time (try ldd on a binary).
.so    is used at build time only.

> and if there needed to be a "-devel" package, it would have
> header files in /usr/include.  

Of course -devel also have the header files.
Most server installations doesn't need -devel stuff.
It's even a security need to remove all the building stuff (gcc...)

> 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. 

Yes, compat-* or some other name.

For example :
   # rpm -ql compat-libf2c-34
   /usr/lib64/libg2c.so.0
   /usr/lib64/libg2c.so.0.0.0
   # rpm -ql mysqlclient14 | grep lib64
   /usr/lib64/mysql/libmysqlclient.so.14
   /usr/lib64/mysql/libmysqlclient.so.14.0.0
   /usr/lib64/mysql/libmysqlclient_r.so.14
   /usr/lib64/mysql/libmysqlclient_r.so.14.0.0

Usually, when an ABI change occurs on the distro, all other
packages requiring the lib are rebuild.
compat-* RPM is provided when this is not possible.

> 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

Using the split solution, you can install mysql++-1.7 and mysql-2.2.1
as there is no file conflicts.

You can only install one -devel.


> 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
> 

Remi.
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