ancient openssl bundled

Enrico Weigelt enrico.weigelt at
Tue Mar 27 10:48:49 PDT 2012

> 	:-) if you have fixes / improvements they are most welcome. Clearly
> waiting for an up-stream release (eg. gnumake - at over 12 months
> since the last release), is not always an option - at which point, you have
> to patch the pristine source tar-ball; checkout the patch count on most
> working linux distributions :-)

In that case: join in the upstream project or the distros to fix the
problem at the source.

About 10 years ago, I've started the "OSS QM project" which tried to do
some kind of overlay repository for all those packages where upstream
is too slow (or sometimes even unwilling) to do necessary fixes, which
are left to the distros (but instead doing general fixes instead of
distro-specific hacks). I've utilized this, eg., in several of my
embedded projects (eg. at that time many fundamental packages were
simply not crosscompilable out-of-the-box, quite often due the
conceptionally broken nature of autotools). Unfortunately, nobody
(outside my own consuming projects) joined in - distros and upstreams
prefered not to speak with each other :(
(often silly rivals between distros, etc).

> 	Sounds like they fell into the embedded linux trap, and needed to
> standardise on a better setup shared with others, pocky / Yocto or
> something. I agree with your analysis here.

Yep, but that's not a technological problem. Proper technologies are
available for long time (I've also got my own one here, but others
like eg. PTXdist also would have suited fine here). Instead it's a
mental problem of the decision makers. Not even an economic issue,
as I showed by cost numbers.

> So - perhaps I just don't understand the alternative well enough;
> lets assume we find a build bug in openssl on some minority platform - say
> AIX, what does your perfect-world flow look like :-)

Report it to openssl project. They'll keep up quite fast.
And, of course, inform the AIX package maintainer. Maybe the fix
will take a while to get into upstream, but that's not a problem if
the according distro(s) react fast enough.

On the other hand: if you bundle a package, you'll need to do virtually
everything that the distros normally do (for that package).
Perhaps you can get your fix used a few days earlier, but this requires
you to have the necessary resources to do the whole maintenance all
on your own. Do you really have them ?


More information about the LibreOffice mailing list