It'd be lovely to have that done & tested :-) of course, some
careful
work is needed to ensure that the existing patches are either forward
ported, or checked to ensure that they are no longer needed.
ACK. The existance of those patches already shows the problem I was
talking about in my previous mail.
Most of the patches are ancient, against ancient versions, completely
outdated. Many of them are only quick and dirty hacks for the bundled
building (often simply done just because the package's build system
was not driven correctly).
Folks, this is the typical maintenance hell, I've already seen in
lots of commercial/inhouse projects, that most likely come from the
unwillingness of certain managers that don't want to invest a few
resources in clean long-term solution (and fail to see that such
hacks become magnitudes more expensive in the longer run). Just look
at any larger former-commercial codebase, Mozilla is also good
example for this.
Just a sidenote: in one of my recent projects, i've been working on
for about a year, we had exactly the same problem. It's a software for
medical data aquisition computers und Linux embedded devices.
These guys had bundled all the 3rdparty packages (beginning with an
*really* ancient kernel, with really dirty hacked patches - up to
lots of userland libraries). The build system was utterly complex
and untable (when I came in, it only worked on an ancient customized
Debian system, which of nobody had backed up ;-o). They completely
refused the idea that this mess produces costly maintenance overhead.
They claimed that this stuff wouldn't need to be touched, even while
we *DID* need to touch it exactly for this tasks I was hired for.
And I have real economic numbers on that: on my first weeks I proposed
a cleanup and using a generic embedded distro engine (eg. Briegel or
PTXdist), would have manpower costs of about 10kEUR. Obviously, they
refused and continued the old way. Within that year, this old was
produced costs in the scale of 50kEUR (without solving the actual
problem, so I guess these costs will come every year, again and again).
Well, these jerks were funny anyways: they're using MSVC for coding
(via SMB shares) and use Team Foundation Server als source control
(more precisely: what they belive in what source countrol would be).
I've measured the extra costs compared to git: about 2kEUR per month.
cu
PS: please forgive me, if I'm a bit too emotional, but I really hate
seeing resources burned on nonsense.
Context
- Re: ancient openssl bundled · Enrico Weigelt
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.