[TriLUG] Debian Sid/Unstable

[Kevin Hunter Kesling]

At 11:25am -0500 Fri, 28 Feb 2014, Sean Alexandre wrote:
> On Fri, Feb 28, 2014 at 09:53:31AM -0500, Kevin Hunter Kesling wrote:
>> I recall noting that Apple's solution to the DLL-hell of Windows
>> was to encourage application-specific copies of common libraries.

>> I'm curious -- for exactly the reason you mention about packages X
>> and Y having conflicting system library requirements -- why at
>> least the desktop Linux distributions haven't attempted to migrate
>> to something along these lines.
>
> I'll take a stab at this, and I'm only speaking as a Debian user...
>
> I can think of two reasons: (1) system stability, and (2) security.
>
> On (1): Debian does a good job of making sure everything
> iteroperates. Having multiple versions of the same thing makes this
> harder. Granted, if this is just a couple of client apps that don't
> interoperate it shouldn't be a problem. But, if it's different
> server pieces talking to each other it could quickly get messy.

Huh, I don't see this.  The whole point of what I'm getting at is that 
dynamically loaded libraries are built per application.  If a system 
piece needs to talk to another, the general wisdom is to talk over a 
clean interface.  For example, ESR talks about this in Chapter 1 of The 
Art of Unix Programming and has this as the first rule of Unix 
programming philosophy:

     1. Rule of Modularity: Write simple parts connected by clean
        interfaces.

In the same chapter, he writes:

     Unix tradition strongly encourages writing programs that read
     and write simple, textual, stream- oriented, device-independent
     formats. Under classic Unix, as many programs as possible are
     written as simple filters, which take a simple text stream on
     input and process it into another simple text stream on output.
     Despite popular mythology, this practice is favored not because
     Unix programmers hate graphical user interfaces. It's because if
     you don't write programs that accept and emit simple text
     streams, it's much more difficult to hook the programs together.

In other words, if two server pieces are talking, they should either be 
built as a unit (in which case they would be one server piece, from a 
library standpoint), or over a well-defined interface, so that neither 
relies on the other's assumptions about their respective libraries.

Am I missing a pragmatic example that you have in mind?

> On (2): Debian also seems to do a good job of patching security
> holes when fixes become available. It would be harder to do this if
> the hole had to be patched in multiple places.

This is a stronger argument to me, but, provided a robust build and 
dependency environment, not one I fully buy.  That said, I must cede 
this point as I cannot argue it from a place of experience[1]: I have 
not worked with any distro-wide build systems, and there are perhaps 
(many) minutiae where the devil may play.

Thanks for your input!

Kevin

[1] I did say this came from idle speculation!  :-)