[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Switching /bin/sh to dash without dash essential



Siggy Brentrup <debian@psycho.i21k.de> writes:

> On Thu, Jul 23, 2009 at 11:19 -0400, Sam Hartman wrote:
>
>
>> Folks, there was a longish discussion on IRC starting about an hour
>> ago about dash and bash.
>
> These discussions are extremely long standing :)  The move away from
> bash has been aimed at long before I vanished from the project in 2004.
> I'm really upset that 5 years are not enough to accomplish the move.
>
>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why  we want dash to be essential.
>> If I'm not using dash as my /bin/sh why do I need it?
>
> So you are complaining about a small package (installed size 224)
> becoming essential while forcing the embedded ppl to work around a
> monster (installed size 1236); numbers taken from my Ubuntu laptop
> where both are essential, I hope only for a limited period of time.
> Although preferring CLI over GUI I don't use both of them, I prefer
> zsh for my daily work but my #!/bin/sh scripts are always posixly
> correct.

No, complaining about replacing shackles with handcuffs.

>> If the answer is that we really do want it everywhere independent of
>> what /bin/sh is, that's fine.  However, that's not obvious to me.
>
> As long as /bin/sh refuses extensions to posix I agree with you, but
> bashism has been a cuss word for years before 2004.
>
>> So, a proposal for doing a switch with dash not essential.
>
>> 1) all /bin/sh shells know about each other.

1b) All /bin/sh shells must behave as if they where essential. They
must work while being unconfigured and so on.

>> 2) The prerm script for a /bin/sh shell finds another /bin/sh shell
>>    and updates the symlink if the current /bin/sh link is the one being
>>    removed.
>
>> 3) The postinst for a /bin/sh shell can update the link if it
>>    decides that the installed shell would make a better /bin/sh
>
>> 4) There is a package `the-shell ' that is essential and pre-depends
>>    on one of the /bin/sh shells.
>
> Maybe "posixly-correct-shell" would be a better name.
>
> Summing up you suggest making a virtual package - however it's called
> - essential.  While I think I grok your intentions, I doubt dpkg
> will follow, please read carefully:
>
>   http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8

And what exactly do you mean? Nothing in there about virtual packages.

>> Variations:
>
>> 1) You could have a registration mechanism.  My assumption is the
>>    set is small enough static is good
>
>> 2) I assume that package operations cannot take place between
>>    calling the prerm script and actually removing the package.  If that
>>    is false, you could make sure that you are changing the link to a
>>    configured shell

It is false afaik. You can deconfigure any number of packages before
starting to remove any of them.

>> I really don't mind if we go forward with the current proposal.
>> However, I think I and a lot of other people would appreciate clarity,
>> so far not expressed, about why dash needs to be essential.
>
> See debian-policy cited above.
>
> looking-forward-for-posixly-correct-/bin/sh-ly yours
>   Siggy

Say you have only shell-1 installed to provide /bin/sh. The big
question is if apt/aptitude/synaptic/.../dpkg will ever deconfigure or
even uninstall shell-1 before it unpacks shell-2.

Can the following sequence happens?

deconfigure the-shell
deconfigure shell-1
remove shell-1
unpack shell-2
configure shell-2
configure the-shell

If this sequence ever happens then the system is without /bin/sh for a
time. Not a good idea.

I think the above is unlikely but can possibly happen and nothing in
Depends or Pre-Depends can prevent it. But the prerm script could
(should) fail if it can not find another /bin/sh provider to at least
don't make the system unusable.

MfG
        Goswin


Reply to: