On 3/26/2019 5:24 AM, Nicolas Mailhot wrote:
Le 2019-03-26 12:29, Dridi Boukelmoune a écrit :
On Tue, Mar 26, 2019 at 8:43 AM Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx> wrote:
Le 2019-03-25 22:47, Japheth Cleaver a écrit :
> If you can take a one-time hit to
> remove bashisms and get a 25-40% improvement,
CPU time is cheap, packager time is not. Exchanging CPU time for "you
all should learn to write POSIX-only shell scripts" would be an awful
deal. The Java part of Fedora is slowly imploding right now because a
lot of people pushed their complexity on packagers, and the packagers
could not cope. The Fedora target should be to help packagers achieve
more with less work, not achieve less with more work.
I think the Java ecosystem is before all imploding because of build
tools
promoting a quadratic complexity of dependencies in a "community" not
bothered to maintain compatibility in libraries and as a result the
other
side of the community coin not updating dependencies they consume
unless they feel like they need it.
It's an ecosystem where tools do not orient devs towards easy to
integrate choices. It's imploding because someone decided a long time
ago @SUN not to bother optimising the integrator/packager time,and all
the efforts to change the Java community values since have failed (and
someone should look hard @RH why it has not leveraged its stake in
JBoss/OpenJDK to improve the situation).
Another victim of those choices and Java ecosystem values was Oracle
that found itself unable to release timely JDK security fixes when it
had to in the first years after it bought SUN, the integrator chain it
bought from SUN was that much broken.
Packager time is not cheap, it's not inexhaustible, it runs out.
Wasting it on bashisms is not smart.
Packager time -- either within the Fedora project, or among the system
users, system administrators, and system engineers of Linux
distributions derived directly or indirectly from Fedora -- is not
cheap, I agree. But getting things Right is important, because it
provides a foundation for those below you to make competent decisions
based the calls made earlier.
Having had to deal with packaging java apps up myself for quite a while
now, I'd agree that it's a hot mess and has been for some time. The
tooling around the original ecosystem seemed to have no rhyme or reason
with it, JPackage efforts never *fully* went anywhere, modern Java devs
still (in my experience) have difficulty getting onboard with attempts
by local OpsEng and admins to wrangle some site-level sense at things.
It doesn't work for anyone. (I'm sure I'm not the only admin who rues
this every time they have a 15-line process string in their 'ps'
output.) Arguably the "Linux is too hard to have to grok" mentality
among java app devs has driven some part of the tech industry's current
trends.
However, I think the parallel with bashisms fails. Getting shell right
is only as difficult as you make it and we're talking about syntax
cleanup, not imposing a new paradigm on a lawless ecosystem. True, the
other major Linux ecosystem that did this had always held a
/bin/sh-stays-POSIX distinction in mind, and had made occasional audit
efforts before, so it was easier. But they faced their own issues at the
same time when they did their conversion... (Their init script
environment (IMHO) was far less disciplined than RH's was at the time
(and still is in rhel6), so there's that.) Nevertheless, we have a clear
example here of how it's possible to get it done.
The fixes to RPM to make this even possible shouldn't be difficult.
Bourne shell remains the shell language (unless otherwise specified for
that scriptlet), but the "default Bourne shell" should be configurable
-- everything else is. In theory, RPM is still the specified package
format for LSB, so the more flexibility for weird environments the
better. And Fedora overriding that to /bin/bash after that (if desired)
seems trivial as well.
As far as actually making changes in specs, let's try addressing that
separately and perhaps asynchronously. Most of the changes for things
likely to run in scriptlets are probably just straight mechanical
replacements. (We won't know until someone does a full scan, but I'd bet
if you're writing *really* complex stuff there, you've probably already
moved that to a packaged script that's executed as part of the scriptlet
instead.) That advancement because a nearly insurmountable effort if we
continue to, by policy, refuse at a core level to distinguish between sh
and bash.
-jc
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
