Dne 27. 03. 19 v 10:30 Dridi Boukelmoune napsal(a):
> 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?
Is there a way to do something similar to:
~~~
%check
pushd .%{gem_instdir}
# Load nio4r_ext.so.
rspec -I$(dirs +1)%{gem_extdir_mri} spec
popd
~~~
But honestly I don't care if /bin/sh is Bash or something different as
long as my script runs in our build environment.
Vít
>> 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
_______________________________________________
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
