Re: ancient openssl bundled

>       Sounds good to me; as/when you have a nice, working package
>       management
> system for Windows & Mac, that is invisible to the user, and handles
> one-click application downloads, creates no extra unwanted UI
> interfaces, and deals with version requirement skew across unrelated
> applications [ unwinding the Windows DLL hell ], then we'll want to
> use
> it I'm sure. You could try poking at what the CoApp guys do, they
> have
> some similar ideas, but it's not such an easy problem to solve I
> think.

Yep, that's a really good hint.
I'd like to encourage the windows folks here to jump on that train.

I, personally, can't be of much help here, as I've lef the M$ world
over 15 years ago (dont even have a single windows instance since that)

> > > If your intention is to update the internal opensssl, then the
> > > best
> > > is to do that in a bug in our bugzilla
> >
> > No, I absolutely don't intend that.
>
>       Shame :-) someone needs to update that thing and re-validate it.

NAK. Someone needs to drop them. (as explained earlier)

Assuming the window folks go on the coapp route (or something similar),
we'll have no need for bundling them anymore in near future.
They can switch off building/using the bundled libs one by one
(as already on *nix side by the --without-system-foo switches)

I'll maintain my downstream fork dropping the 3rdparty packages step
by step. (I'll contigiously rebase, to I'll be ontop of master).

Once windows are ready to live without a certain 3rdparty package,
we can take the appropriate patch from my branch to mainline.

But for all of this, the main strategy must be clear: move the
dependency handling to out of the application layer to the distro
layer.

> > I've already seen that reaction coming. Seen the same in dozens
> > over
> > dozens of other projects in the last 15 years. None of these
> > projects
> > ever agreed do solve that problem once and for all by a generic
> > solution
>
>       So - perhaps sitting down and understanding why developers don't go
> routinely updating their external libraries and solving the problems
> they see there might work - why do we have an ancient openssl
> internally ? is it the pain of re-basing our patches ? is it that we
> are conservative & scared of touching things that appear to work ? :-) 

Probably both: manually rebasing patches is ugly. That's why clever
people invented SCMs like git. And, oh, that's also why the concpet
of modularization was invented somewhen in the 60th of the last century.

Being scared of what changes might changes might do might be another
reason. In the linux embedded project I meantioned in earlier mail,
I was really the only person who knew how to configure and build a
kernel in that team, until about half a year another freelancer came
into the team (but unfortunately was allocated for a completely
different product). Again, that's yet another reason why the concept
of modularization was invented (unncessary to mention that modules
and libraries are completely different concepts).

> is it that it is hard to test changes on mutiple platforms, and
> external deps tend to be the most fragile pieces ? would a gerrit
> flow help that ? etc.

Yes. And that's why distros were invented. They know their scope
(supported hardware, involved software, user requirements, etc, etc)
very well. All of these things we cannot really handle properly in
an application development project. If wanted to, we needed to do an
full-blown distro on our own.

The bottom line is: you've raised good arguments. Against bundling.

>       Ultimately, the overhead of shipping duplicates seems somewhat small
> size-wise in a world where people virtualise & duplicate whole
> operating
> systems on their devices in virtual machines, at least compared to
> the
> convenience of pseudo-application-virtualisation ;-)

Distribution size is not an argument anymore. But RAM requirements
still is - these bundled libraries cannot be shared with other
applications. (well, in *theory* this *could* be done, in specific
cases, when other applications use mostly *equal* binaries, using
KSM - but how likely is that ? ;-o)


cu