:-) 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 ?
cu
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.