[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#692155: Please



On Fri, Nov 02, 2012 at 04:41:19PM -0700, Russ Allbery wrote:
> "Didier 'OdyX' Raboud" <odyx@debian.org> writes:
>...
> > Le vendredi, 2 novembre 2012 23.47:11, Russ Allbery a écrit :
> >> In practice, divergence from the upstream SONAME practice is probably a
> >> bad idea.  This business of having an exposed private API is dangerous and
> >> constitutes bad API design on upstream's part, but that's not something
> >> that we can easily fix in Debian, and diverging too far from upstream is
> >> probably counter-productive.
> 
> > That's the crux of the problem indeed. The "good way" would be to have a
> > libcupsprivate, shipping its objects outside of standard library paths,
> > right?  Sounds like an invasive bug, not sure that it would be worth the
> > work.
> 
> Actually, it could ship in the regular shared library path.  It would just
> change its SONAME a lot, which would be fine, since no other applications
> would link against it and therefore no one would really care.
>...

Having a SONAME for such a library would cause other problems, e.g. the 
changes cherry-picked into 1.5.2-8 (that caused #668662) could result in 
a private library whose ABI would not match any upstream SONAME.

Not an unsolvable problem (one could even automatically encode version 
and Debian revision into the SONAME), but also not much nicer than the
status quo.

> The solution that I use is to just refuse to let myself use the concept of
> a private API and make all of the things used internally by my software
> public APIs as well, absorbing the maintenance costs that entails.  But I
> understand why people don't do that.  :/
>...

Sharing code between different components (that are in different Debian 
packages) in a software with much development going on without having to 
continue to provide and maintain any such shared code for 10-20 years is 
the problem CUPS is trying to solve that way.

Creating a libcupsprivate that is a static library (which also has
it's drawbacks) might be another approach for an upstream to solve
this problem.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


Reply to: