Re: [Sks-devel] SKS debian package

[Jeffrey Johnson]

On Apr 29, 2012, at 4:59 PM, Christoph Anton Mitterer wrote:

> On Mon, 2012-04-23 at 18:59 -0400, Jeffrey Johnson wrote:
>> And your opinion is contrary to what was recommended.
> Well this is not just my opinion but decades of lectures learned in
> software design…
> 

I'm reporting what was recommended. If you want to compare
pedigrees, we can do that as well.

> I'm not generally against static linking, but there must be really
> really really strong reasons to do so…
> 

For starters I recommended per-application bundling. You
seemed to understand static linking, so I continued
a discussion on a model that is isomorphic to static linking.

> Making life a bit easier for packaging is definitely not a reason.
> 

Uncoupling the ability to upgrade the application from
upgrading the entire system has nothing to do with
packaging.

> 
> A reason could be, if that would make usage of a BDB much faster, but
> even this would IMHO only count, if we already see severe performance
> problems (and actually one should then discuss whether it's not time to
> go to a more powerful DBMS),... but even my really small crappy server
> with basically no RAM, still runs just fine.
> 

Nothing you just said makes any sense to me.

> 
>> The tradeoff is whether you want to maximize application
>> independence from Berkeley DB or minimize efforts when updating everything
>> that uses "system" Berkeley DB.
> 
> I don't want to step on anyone's toes,.. but sks is probably not the
> project with the highest activity in the world (actually it has no need
> to be, because it rund fairly well)... so I doubt that there would be
> updates "immediately" when new BDB versions are out.

There is both no impediment (because of "backward compatibility"),
nor urgency (because the basic functionality is largely the same).

> In general,.. static linking sounds always fishy when it comes towards
> security.
> 

New versions can regress: there are sound reasons _NOT_ to
have to deal with security issues by bundling per-application.

Meanwhile there really hasn't ever been a "security issue" that
always using "system" Berkeley DB has avoided. Ever.

> 
>> Statically linking Berkeley DB was claimed to be ~175K 
>> when tuned for a minimal memory footprint without all
>> the bells and whistles. The code footprint in memory is
>> certainly small.
> Yeah,.. of course,... but that's not the point, IMHO.
> Even if it would add 10MB,... who cares…
> 

Someone will care. *shrug*

> 
> 
> After all,... the best thing for users was, if they have sks available
> in their distro's official repositories,... and at least in the Debian
> case I can tell you, that they'll surely dislike if you statically link
> against something with not really strong reason.
> 

The best thing for users -- particularly Debian users -- is
        Less is more.
Choose a version of Berkeley DB, port to that version, ignore
the rest. Providing 5+ year old versions to continue applications
that are seldom changed and even more seldom used, was
the point of my original comment.

But I don't use Debian: do as you wish.

73 de Jeff