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

Re: Issue with dpkg-shlibdepds



First of all, TOFU is generally frowned upon as a posting style on technical 
mailing lists.

Second, IANADD and TINASOTODP; I speak only for myself.

On Tuesday 01 September 2009 08:55:45 Joe Smith wrote:
> We're making a set of interface libraries for use in cross-platform
> application development. We want to 100% guarantee that if an application
> is compiled against a particular version of the library, then it's
> guarateed to work indefinitely with the same level of functionality.

I think this is an unreasonable goal.  That said, even if it is to remain the 
goal it should be implemented through disciplined library development and a 
thorough test suite, not through the linker.

You *should* use the linker to retain backward compatibility (symbol 
versioning) and you *should* use other technical means to detect ABI changes 
before a release.

> As
> such, we can't upgrade the libraries underneath or we risk regression.

This is misguided.  If there is a security issue in the library, it needs to 
be able to be fixed in one place without recompiling all the programs that use 
the library.

> Plus
> this way we can break binary compatibility without issue between versions.

While I guess it makes the library user happy, it will not make the 
application developers or packagers happy.

Also, having so many versions that appear incompatible to the linker when they 
are actually compatible defeats the purpose of shared libraries; applications 
are much less likely to share them.  This increases both RAM and HD usage 
needlessly.  The increased RAM usage can also cause longer run times 
indirectly as there are more cache misses.

> The other problem is that applications built against different versions can
> be installed at the same time, and thus different versions of the actual
> libraries themselves must also be installed at the same time. For this, I
> don't see how we can get around it with a single package name.

You might be able to have a single source package, but most likely you will 
need a different source package for each version.

> The other option is to forget packaging altogether for the libraries and
> package them with each application instead, but it would be more work for
> the application developer to deal with that.

It would also be more work for the security team.

You might be able to use static linking, but that's generally frowned upon on 
Debian.  Shipping the library along-side the application is also generally 
frowned upon.
-- 
Boyd Stephen Smith Jr.           	 ,= ,-_-. =.
bss@iguanasuicide.net            	((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy 	 `-'(. .)`-'
http://iguanasuicide.net/        	     \_/

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: