On Wed, Mar 27, 2019 at 8:33 AM Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx> wrote:
>
> Le 2019-03-27 03:46, Nico Kadel-Garcia a écrit :
> > On Tue, Mar 26, 2019 at 3:44 AM Nicolas Mailhot
> > <nicolas.mailhot@xxxxxxxxxxx> wrote:
>
> >> POSIX is dead as a shell compatibility target. You want to replace
> >> bash
> >> with something faster, by all means do it. With something that
> >> includes
> >> the GNU extensions like pushd/popd that most packagers expect today.
> >
> > Is there any reason to *ever* use pushd or popd in %build or %install
> > today?
>
> That is totally the wrong attitude when you want to replace an
> implementation used for years by thousands of volunteer people in tens
> of thousands of interdependent files.
Again, not interested in the side of the discussion about replacing
bash as the default interpreter. This is a reminder that I would
personally prefer that bash weren't behind /bin/sh.
> It is used now, ergo packagers (the people who did the work) find it
> useful and convenient. You want them to do something else, you need to
I strongly disagree with the shortcut you make here.
The only use of pushd/popd I made in scriptlets was because it was
part of the Python packaging guidelines and I happen to maintain a
bunch of Python packages. So what I was doing then wasn't to choose
something I would deem useful and convenient but rather follow
guidelines to the best of my abilities.
So sure some people may find it useful and convenient, but others may
not even be aware or care that this construct is bash-specific so
please refrain from authoritatively introduce causality where there
isn't.
And on the convenience factor:
pushd somewhere
...
popd
is not harder than:
cd somewhere
...
cd -
The bash construct becomes interesting only when you need to stack
directories and not keep explicit track of where you are returning to.
This convenience I do not wish to remove from package maintainers,
even in scriptlets.
> make it worth their effort to something else. Winning 10 minutes of CPU
> time in a single pathological spec like gcc isn't it.
>
> The easiest way to make it worth their effort is to reduce the effort to
> zero, ie implement the capabilities commonly people use in your target
> replacement shell. That will be way way easier than trying to invent
> something compelling enough for them to change their habits. 10% of
> specs doing something is definitely common use.
>
> Another way is to take the conversion work unto yourself. But that does
> not solve the ongoing effort of helping packagers that try to use bash
> syntax in their spec because they need to do something, and find out it
> does not work, and give up because the additional work of looking for
> alternatives makes the cost/benefit analysis of packaging something
> negative. We have many packages where the cost/benefit hovers next to
> the limit, because we have nice volunteers that will go to their limits
> for Fedora.
Conversely whenever as a Fedora end user I run into a failing script
on a non Fedora system because it uses GNUisms it makes my life harder
to work on the multiple systems I have to deal with. By having bash as
/bin/sh Fedora defers the moment when I realize this is happening and
pain ensues. That is because Fedora is my main system and others are
second-class citizens in my workflow. I'd hate to elect a different
one as main my system for obvious reasons.
> Yet another is to propose a syntax with is clearly simpler, more
> expressive, more productive and better documented for humans (Not CPUs.
> CPUs do not get to vote). But, that solves "new spec and macro code"
> problem, not the "existing code" problem.
>
> Hazing people with negative terms like bashism never convinced anyone.
I'm sure some comments of this nature actually got a "fair enough"
response from a couple people.
> Especially when others are doing the work, not you. In my language, that
> is called “arriving after the battle”: complaining loudly at the people
> who sweated and blooded doing some work, that they didn't do it well
> enough, when you were safely somewhere else, at the time help was
> needed.
I am personally taking an opportunity to raise my concern about the
default shell seeing this after-the-battle thread.
Maybe I should start a different one on /bin/sh?
I was not aware of this until the link was shared in this thread but
this is an interesting read on the topic:
https://wiki.ubuntu.com/DashAsBinSh
If RPM goes somewhere on this topic [1] maybe that could be a change for f31?
Dridi
[1] https://github.com/rpm-software-management/rpm/issues/646
_______________________________________________
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
