> :-) 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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice