[packagers] Shared libraries in RPMforge packages...

[Tom G. Christensen]

Kjeldgaard Morten wrote:
> Tom G. Christensen wrote:
> 
>> What if another package depends on the openexr3 binaries?
> 
> That's a pretty contrived point IMHO. Yes, another program _may_ spawn a 
> process with one of these binaries, but binaries are usually invoked in 
> the same manner, and with the same options. Of course, a binary could 
> disappear from a package. The probability of this hurting someone is 
> very low. But, as you say, it's a matter of policy ;-)
>
The new binaries may behave completely differently and have different 
arguments etc. so not so contrived as you make it out IMHO.

Since you seem to care a great deal about stuff *NOT* packaged as RPMs 
breaking when a package is updated I don't understand how you can just 
dismiss binaries going away as not a problem.

>> Allowing -devel packages to coexist in this way is more work since it 
>> will require modification of every single upstream package that need 
>> to find the headers.
> 
> Not really, since this should needs to happen if the API changes which 
> --after all-- are quite rare. In the case of an API change the upstream 
> developers of client packages will need to do something actively, so 
> we'll always have two sets of packages: those that depend on the old 
> version and those that depend on the new. FFTW is an example.
>
Say openexr puts its headers in /usr/include/openexr.
Any program that links with openexr knows that and uses include 
<openexr/blah.h>.
Now you propose to move headers to /usr/include/openexr3 and 
/usr/include/openexr4 to allow them to coexist.
How are upstream sources supposed to find the right headers without 
modification?

>> Also how do you handle that the -devel package usually contains a 
>> symlink pointing to the shared library with the unversioned name? This 
>> would clash in your example:
>> openexr3-devel:
>> /usr/lib/libIex.so -> /usr/lib/Iex.so.3.0.0
>> openexr4-devel:
>> /usr/lib/libIex.so -> /usr/lib/Iex.so.4.0.0
> 
> Good point. Basically, it is the responsibility of the upstream 
> developers to make sure that this does not happen. The FFTW folks did 
> this by making sure that the libraries that come with version 3 are all 
> named libfftw3*. That solves the problem, since the you get
> 
> libfftw.so -> libfftw.so.2.0.5
> libfftw3.so -> libfftw3.so.3.1.2
> 
> Granted, not all upstream developers are distribution-aware. In the case 
> of openexr, we'd have to either bug the developers, or rename the 
> libraries during packaging. If the package uses libtool, that fix is 
> trivial. It gives more work for the package maintainer, but that is the 
> price to pay if you want a professionel distribution and not a toy one.
> 
I see now.
You want that upstream should already have anticipated this and 
versioned libraries and header directories etc to coexist.
I disagree with that and I don't think upstream should generally prepare 
for this.
With versioned include files in particular it quickly becomes a 
nightmare for developers. How can they know which include directory to use?

It's IMHO a function of the distribution if they care to have it so that 
previous versions can coexist on a larger scale.

>> It's not like people are not warned about what is happening, you said 
>> yourself that apt-get would not allow you to install the update 
>> without removing the packages that depended on the old version.
> 
> That is only true if _all_software is installed using RPMs. Many sites 
> have locally compiled software sitting in /usr/local that depend on 
> shared libraries without this dependency being recorded in rpmdb. In 
> this case, apt-get will merrily update the packages and leave locally 
> compiled software broken.
>
That's were our opinion differs. I see nothing wrong with that scenario 
at all and I cannot see why RPMforge should go to any length to support 
such an installation.
I don't think RPMforge should really care about anything that is not 
packaged as RPMs with proper deps to resolve.

> We start meeting these problem now because we are no longer packaging 
> for Fedora. With Fedora, completely new releases are coming out all the 
> time, and traditionally, people have just upgraded the whole system at 
> once. With Fedora, problems are reset every six months.
> 
Are you referring to your own local packages?
I assume you must be since RPMforge has been dealing with the longer 
lifetime of RHEL for years.

> With CentOS, we have a much longer turnaround time, and packages are 
> gradually updated along the way. That is why these problems start 
> appearing now, and it is necessary to do something about them. RedHat 
> does not care, because they don't support the mass of third party 
> software, only the RPMs _they_ distribute. Their lack of care is 
> reflected into CentOS' codebase.
> 
I don't see Redhats policy as lack of care. Its a choice and one that 
RPMforge seems to currently mimick though perhaps it's not a conscious 
choice from Dag.

> PS: Tom, we are about 500m from each other, perhaps we should meet for a 
> cup of coffee one day... :-)
> 
I had wondered if you weren't located somewhere on campus :)

-tgc