FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-05-2011, 09:11 PM
Luk Claes
 
Default Shipping /bin/sh

On 04/05/2011 11:05 PM, Jonathan Nieder wrote:
> Carsten Hey wrote:
>> * Steve Langasek [2011-04-04 19:37 -0700]:
>>> On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote:
>
>>>> * Find a sane solution for managing /bin/sh. Currently diversions are
>>>> used, which looks like the wrong tool for this job to me. There are
>>>> also some related bugs with a high severity.
>>>
>>> Also seems to be orthogonal.
>>
>> I agree that this seems to be orthogonal at first, and even second,
>> sight.
>
> And third. The correct way to manage /bin/sh is as a configuration file.
> That means:
>
> * dash would stop shipping /bin/sh in its data.tar
> * bash would stop shipping /bin/sh in its data.tar
> * an essential package (doesn't matter which --- maybe debianutils)
> should take care of allowing other shells to influence where
> /bin/sh points.
>
> Policy 10.7.4 ("Sharing configuration files") spells this out. It
> doesn't have much to do with whether dependencies on bash are made
> explicit.

Well, that will only happen when it's cristal clear that it's guaranteed
that /bin/sh exists and is functional at all times in such a scenario.

You are welcome to implement such a solution, but if it does not meet
the above criterion, it will very probably not be adopted.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D9B8580.6010500@debian.org">http://lists.debian.org/4D9B8580.6010500@debian.org
 
Old 04-05-2011, 11:55 PM
Carsten Hey
 
Default Shipping /bin/sh

* Luk Claes [2011-04-05 23:11 +0200]:
> On 04/05/2011 11:05 PM, Jonathan Nieder wrote:
> > Carsten Hey wrote:
> >> * Steve Langasek [2011-04-04 19:37 -0700]:
> >>> On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote:
> >>>> * Find a sane solution for managing /bin/sh. Currently diversions are
> >>>> used, which looks like the wrong tool for this job to me. There are
> >>>> also some related bugs with a high severity.
> >
> > The correct way to manage /bin/sh is as a configuration file.

Of course it is.

> > * dash would stop shipping /bin/sh in its data.tar
> > * bash would stop shipping /bin/sh in its data.tar

How would debootstrap be able to run the preinst scripts without
a working /bin/sh, unless it runs bash's binary one first?

> > * an essential package (doesn't matter which --- maybe debianutils)
> > should take care of allowing other shells to influence where
> > /bin/sh points.

update-alternatives is (among other things) because of the indirection
it uses the wrong tool, but a part of it fits rather good. Such a tool
would need to support priorities to select per default dash as /bin/sh,
if dash is not installed it would select bash and if both are missing it
would select an other shell. It would also need to assure that whilst
it is running /bin/sh is always functional. Passing a shell to it that
is not included in /etc/shells could lead to failing of this tool,
unless --force is used.

> Well, that will only happen when it's cristal clear that it's guaranteed
> that /bin/sh exists and is functional at all times in such a scenario.

Guaranteeing that /bin/sh exists and is functional during debootstrap,
even before any maintainer script has been run, could be archived if
every system shell would provide /bin/sh pointing to itself. To avoid
file conflicts, all but the one whose preinst is run first (finding
a clever way to detect this shouldn't be that hard) could divert their
/bin/sh to /bin/sh.$SHELL. When update-shell (or whatever it's name
would be) finally takes over managing /bin/sh, it could divert the
remaining /bin/sh away and replace it with a symlink not known to the
packaging system.

Running update-shells in postinst and prerm (and never in the other two)
would additionally be required to ensure that /bin/sh is always
functional.


Regards
Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110405235520.GA5860@furrball.stateful.de">http://lists.debian.org/20110405235520.GA5860@furrball.stateful.de
 
Old 04-06-2011, 05:20 AM
Luk Claes
 
Default Shipping /bin/sh

On 04/06/2011 01:55 AM, Carsten Hey wrote:
> * Luk Claes [2011-04-05 23:11 +0200]:
>> On 04/05/2011 11:05 PM, Jonathan Nieder wrote:
>>> Carsten Hey wrote:
>>>> * Steve Langasek [2011-04-04 19:37 -0700]:
>>>>> On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote:

> Guaranteeing that /bin/sh exists and is functional during debootstrap,
> even before any maintainer script has been run, could be archived if
> every system shell would provide /bin/sh pointing to itself. To avoid
> file conflicts, all but the one whose preinst is run first (finding
> a clever way to detect this shouldn't be that hard) could divert their
> /bin/sh to /bin/sh.$SHELL. When update-shell (or whatever it's name
> would be) finally takes over managing /bin/sh, it could divert the
> remaining /bin/sh away and replace it with a symlink not known to the
> packaging system.

That unfortunately does not work as diversions are only meant to be used
when 2 packages provide the same file. One of the problems being what to
do when you remove one of the shells (for instance the one providing
/bin/sh)...

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D9BF825.4090906@debian.org">http://lists.debian.org/4D9BF825.4090906@debian.org
 
Old 04-06-2011, 10:22 AM
Simon McVittie
 
Default Shipping /bin/sh

On Wed, 06 Apr 2011 at 01:55:20 +0200, Carsten Hey wrote:
> It would also need to assure that whilst
> it is running /bin/sh is always functional. Passing a shell to it that
> is not included in /etc/shells could lead to failing of this tool,
> unless --force is used.

Not everything in /etc/shells is POSIXy enough to be /bin/sh. The *csh family
aren't Bourne shells, and while zsh is a very nice Bourne-ish interactive
shell, in its default configuration it isn't POSIX-compliant.

smcv (a zsh user)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110406102207.GA18670@reptile.pseudorandom.co.uk" >http://lists.debian.org/20110406102207.GA18670@reptile.pseudorandom.co.uk
 
Old 04-06-2011, 11:55 AM
Vincent Lefevre
 
Default Shipping /bin/sh

On 2011-04-06 11:22:07 +0100, Simon McVittie wrote:
> Not everything in /etc/shells is POSIXy enough to be /bin/sh. The
> *csh family aren't Bourne shells, and while zsh is a very nice
> Bourne-ish interactive shell, in its default configuration it isn't
> POSIX-compliant.

When invoked as sh, zsh should be in a POSIX-compliant configuration.
The main problem is that AFAIK, it still has bugs...

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110406115509.GB13707@prunille.vinc17.org">http://lists.debian.org/20110406115509.GB13707@prunille.vinc17.org
 
Old 04-07-2011, 12:05 AM
Carsten Hey
 
Default Shipping /bin/sh

* Luk Claes [2011-04-06 07:20 +0200]:
> On 04/06/2011 01:55 AM, Carsten Hey wrote:
> > Guaranteeing that /bin/sh exists and is functional during debootstrap,
> > even before any maintainer script has been run, could be archived if
> > every system shell would provide /bin/sh pointing to itself. To avoid
> > file conflicts, all but the one whose preinst is run first (finding
> > a clever way to detect this shouldn't be that hard) could divert their
> > /bin/sh to /bin/sh.$SHELL. When update-shell (or whatever it's name
> > would be) finally takes over managing /bin/sh, it could divert the
> > remaining /bin/sh away and replace it with a symlink not known to the
> > packaging system.
>
> That unfortunately does not work as diversions are only meant to be used
> when 2 packages provide the same file.

Actually, this impossible use of dpkg-divert was intended to be a way to
work around the missing (or unwanted?) hook support in deboostrap and
cdebootstrap. Packages in base could use these hooks to set up a part
of what is currently done in /usr/share/debootstrap/scripts/.

Without such hooks, adding /bin/sh could still be done in debootstrap
and cdebootstrap.


> One of the problems being what to do when you remove one of the shells
> (for instance the one providing /bin/sh)...

ksh's prerm script would call "update-shell remove /bin/ksh93". If
/bin/sh would point to ksh93, update-shell would change /bin/sh to point
to the registered system-shell with the highest priority.

System shells would (de)register themselves by calling add-system-shell
in postinst and remove-system-shell in prerm. 'system-shell' would also
be a virtual package provided by bash, dash and so on. Although I don't
think this would be a problem, using /bin/$SHELL in the shebang of
postinst and prerm could prevent possible problems if /bin/sh changes
whilst these scripts are running.


* Simon McVittie [2011-04-06 11:22 +0100]:
> > Passing a shell to it that is not included in /etc/shells could lead
> > to failing of this tool, unless --force is used.
>
> Not everything in /etc/shells is POSIXy enough to be /bin/sh.

This was not meat as whitelist but as "inverse blacklist" (everything
not in it is most probable not a adequate /bin/sh). Anyway, this was
a bad idea.


Regards
Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110407000526.GA27142@furrball.stateful.de">http://lists.debian.org/20110407000526.GA27142@furrball.stateful.de
 
Old 04-07-2011, 10:16 AM
Goswin von Brederlow
 
Default Shipping /bin/sh

Carsten Hey <carsten@debian.org> writes:

> System shells would (de)register themselves by calling add-system-shell
> in postinst and remove-system-shell in prerm. 'system-shell' would also
> be a virtual package provided by bash, dash and so on. Although I don't

How would that work with (c)debootstrap/multistrap when creating a
chroot for a foreign architecture? No maintainer script will be run in
those cases nor can they be run in general.

Some package needs to initially ship a /bin/sh binary or symlink, which
I would think dash should do (being the default sh). And the registering
in postinst could then later replace this with the proper mechanism
(which would still just be a symlink to dash by default I guess).

> think this would be a problem, using /bin/$SHELL in the shebang of
> postinst and prerm could prevent possible problems if /bin/sh changes
> whilst these scripts are running.

In postinst and prerem there is no problem in using /bin/$SHELL since
the shell is already/still present. But what about preinst and postrm?

We can probably assume there will allways be one system shell present so
/bin/sh for postrm is fine. But for preinst we are back to the above
problem. When bootstraping no postinst of any system shell has yet run
so there is no /bin/sh configure. Yet we still need one. Even using an
elf binary as preinst to create the initial /bin/sh link would be ugly
because then bootstraping tools (second stage) need the special
knowledge to run that first.

Which brings us back to the need for some (dash package to ship an
initial /bin/sh before the proper (de)registering mechanism takes over.

Please keep that in mind when designing it.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87bp0igye5.fsf@frosties.localnet">http://lists.debian.org/87bp0igye5.fsf@frosties.localnet
 
Old 04-08-2011, 04:52 PM
Bastian Blank
 
Default Shipping /bin/sh

On Thu, Apr 07, 2011 at 12:16:02PM +0200, Goswin von Brederlow wrote:
> Carsten Hey <carsten@debian.org> writes:
> > System shells would (de)register themselves by calling add-system-shell
> > in postinst and remove-system-shell in prerm. 'system-shell' would also
> > be a virtual package provided by bash, dash and so on. Although I don't
> How would that work with (c)debootstrap/multistrap when creating a
> chroot for a foreign architecture? No maintainer script will be run in
> those cases nor can they be run in general.

We have the same problem with awk since ages. We should fix both
problems together. Therefor I propose the following:

- An essential or pseudo-essential (dependency or pre-dependency from an
essential package) may include a new maintainer script.
- This must be a /bin/sh script.
- It may be called after the initial unpack of the bootstrap process.
- It must be called outside of the new root, so it can assume that it
can execute some essential commands.

The other solution is to hardcode the setup like the awk link.

> Some package needs to initially ship a /bin/sh binary or symlink, which
> I would think dash should do (being the default sh). And the registering
> in postinst could then later replace this with the proper mechanism
> (which would still just be a symlink to dash by default I guess).

This means that we will get a diversion just to please the bootstrap.

Bastian

--
Death, when unnecessary, is a tragic thing.
-- Flint, "Requiem for Methuselah", stardate 5843.7
 
Old 04-08-2011, 05:31 PM
Goswin von Brederlow
 
Default Shipping /bin/sh

Bastian Blank <waldi@debian.org> writes:

> On Thu, Apr 07, 2011 at 12:16:02PM +0200, Goswin von Brederlow wrote:
>> Carsten Hey <carsten@debian.org> writes:
>> > System shells would (de)register themselves by calling add-system-shell
>> > in postinst and remove-system-shell in prerm. 'system-shell' would also
>> > be a virtual package provided by bash, dash and so on. Although I don't
>> How would that work with (c)debootstrap/multistrap when creating a
>> chroot for a foreign architecture? No maintainer script will be run in
>> those cases nor can they be run in general.
>
> We have the same problem with awk since ages. We should fix both
> problems together. Therefor I propose the following:
>
> - An essential or pseudo-essential (dependency or pre-dependency from an
> essential package) may include a new maintainer script.
> - This must be a /bin/sh script.
> - It may be called after the initial unpack of the bootstrap process.
> - It must be called outside of the new root, so it can assume that it
> can execute some essential commands.

You then need a way to pass the location of the chroot to the new
maintainer script. So a slightly different (or extended) interface
compare to pre/posrinst/rm. But this might do as a general solution for
both /bin/sh and /usr/bin/awk. Both could have a (lets call it)
DEBIAN/bootstrap scrtipt.

> The other solution is to hardcode the setup like the awk link.
>
>> Some package needs to initially ship a /bin/sh binary or symlink, which
>> I would think dash should do (being the default sh). And the registering
>> in postinst could then later replace this with the proper mechanism
>> (which would still just be a symlink to dash by default I guess).
>
> This means that we will get a diversion just to please the bootstrap.
>
> Bastian

Indeed. But no pre-bootstrap script neccessary. Is there a debootstrap
for windows (or similar) that would have problems executing a /bin/sh
script?

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k4f4k5ur.fsf@frosties.localnet">http://lists.debian.org/87k4f4k5ur.fsf@frosties.localnet
 
Old 04-08-2011, 06:00 PM
Bastian Blank
 
Default Shipping /bin/sh

On Fri, Apr 08, 2011 at 07:31:08PM +0200, Goswin von Brederlow wrote:
> Bastian Blank <waldi@debian.org> writes:
> > - An essential or pseudo-essential (dependency or pre-dependency from an
> > essential package) may include a new maintainer script.
> > - This must be a /bin/sh script.
> > - It may be called after the initial unpack of the bootstrap process.
> > - It must be called outside of the new root, so it can assume that it
> > can execute some essential commands.
> You then need a way to pass the location of the chroot to the new
> maintainer script. So a slightly different (or extended) interface
> compare to pre/posrinst/rm. But this might do as a general solution for
> both /bin/sh and /usr/bin/awk. Both could have a (lets call it)
> DEBIAN/bootstrap scrtipt.

Well, we could just use the working directory.

> Is there a debootstrap
> for windows (or similar) that would have problems executing a /bin/sh
> script?

No, there is not. Also Windows is not able to write filesystems suitable
for a Debian root filesystem.

Bastian
>

--
The joys of love made her human and the agonies of love destroyed her.
-- Spock, "Requiem for Methuselah", stardate 5842.8


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110408180014.GA31345@wavehammer.waldi.eu.org">ht tp://lists.debian.org/20110408180014.GA31345@wavehammer.waldi.eu.org
 

Thread Tools




All times are GMT. The time now is 05:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org