Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3267 bytes --]

On 03/02/2017 07:36 AM, Marco Atzeri wrote:
> On 02/03/2017 13:36, Steven Penny wrote:
>> On Wed, 1 Mar 2017 23:31:24, Vince Rice wrote:
>>> Then you haven't been paying attention.
>>> And I didn't even attempt to make an argument one way or the other,=20
>>> except to say stop arguing. The horse is dead.=
>>
>> Perhaps you could link to a constructive, concrete idea against the
>> change that
>> someone has made besides Eric. Even better, you could post your own
>> constructive
>> idea; surely you havent emailed twice now with nothing constructive to
>> add?
> 
> He was constructive, but you seems biased in understanding the answer.

To reiterate my answer in different terms:

If you can convince Fedora to switch /bin/sh to dash, then I will
immediately follow in Cygwin.  Until then, I'm worried that there are
enough scripts in the wild that use bashisms and will therefore break if
/bin/sh is not bash, even though that number has reduced somewhat since
Debian made their switch.  Trying to make Cygwin the guinea pig, instead
of Fedora, is going about it backwards (you WANT the change to be done
in a place where there is plenty of manpower to deal with the fallout,
and Fedora has more manpower than Cygwin).

I'm still toying with the idea of doing a test release of both bash and
dash that flips /bin/sh between them; but I'm still stuck on the problem
that a user MUST upgrade (or downgrade) both packages in tandem, or else
risk being left without a /bin/sh at all.  Help would be appreciated in
figuring out the problem (telling me that "dash is faster than bash" is
not help, nor is telling me that "portable shell scripts don't care if
/bin/sh is bash or dash" - I already know those points. What I don't
know is how many non-portable scripts are out there, so how much
breakage would I be causing by forcing those non-portable scripts to
deal with their non-portability, and how to minimize the even-worse
breakage of an upgrade scenario that leaves no /bin/sh at all).

Hmm, maybe I could create a NEW package, 'sh', which packages /bin/sh as
however I want it (probably bash to begin with, to at least give people
time to upgrade and pick up the packaging change before also having to
deal with any shell changing). New releases of both bash and dash would
depend on the new package, to guarantee that if you upgrade one shell,
you pick up the dependency.  And by not having /bin/sh in either the
bash or dash package, then we would at least avoid the current situation
where upgrading/downgrading in the wrong order could leave a user
without /bin/sh at all.  You might still be in a situation where the
wrong version of the 'sh' package leaves you with an outdated version of
a shell, or the wrong flavor in relation to the current distro choice,
but that's less of a problem than having no /bin/sh at all.  In fact,
having a separate 'sh' package may make it even easier to pick which
shell flavor you prefer (if I always keep the 'curr' and 'test' versions
pointed to different shells, then you make the choice of which sh flavor
you want by which version you install).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]