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


 
 
LinkBack Thread Tools
 
Old 05-15-2010, 02:09 AM
Dan McGee
 
Default dash 0.5.6-1

Signoff both architectures, new-ish upstream version. We no longer
build statically with klibc since it doesn't exist; instead this is
linked against glibc. It is still super lightweight though.

-Dan
 
Old 05-15-2010, 05:48 AM
Allan McRae
 
Default dash 0.5.6-1

On 15/05/10 12:09, Dan McGee wrote:

Signoff both architectures, new-ish upstream version. We no longer
build statically with klibc since it doesn't exist; instead this is
linked against glibc. It is still super lightweight though.


Signoff both.

Although... given this is no longer statically linked, does this need
to stay in the base group, or even [core]?


Allan
 
Old 05-16-2010, 09:58 AM
Pierre Schmitz
 
Default dash 0.5.6-1

On Sat, 15 May 2010 15:48:46 +1000, Allan McRae <allan@archlinux.org>
wrote:
> On 15/05/10 12:09, Dan McGee wrote:
>> Signoff both architectures, new-ish upstream version. We no longer
>> build statically with klibc since it doesn't exist; instead this is
>> linked against glibc. It is still super lightweight though.
>
> Signoff both.
>
> Although... given this is no longer statically linked, does this need
> to stay in the base group, or even [core]?

Good question. I had to look it up: Dan introduced the dash package to
have a non-breakable shell in core and a future provider of /bin/sh. But
the latter wasn't implemented yet and no other package depends on it. So I
guess we could safely remove it from core/base and add it to extra.

Greetings,

Pierre

--
Pierre Schmitz, https://users.archlinux.de/~pierre
 
Old 05-18-2010, 04:28 AM
Dan McGee
 
Default dash 0.5.6-1

On Sun, May 16, 2010 at 4:58 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
> On Sat, 15 May 2010 15:48:46 +1000, Allan McRae <allan@archlinux.org>
> wrote:
>> On 15/05/10 12:09, Dan McGee wrote:
>>> Signoff both architectures, new-ish upstream version. We no longer
>>> build statically with klibc since it doesn't exist; instead this is
>>> linked against glibc. It is still super lightweight though.
>>
>> Signoff both.
>>
>> Although... * given this is no longer statically linked, does this need
>> to stay in the base group, or even [core]?
>
> Good question. I had to look it up: Dan introduced the dash package to
> have a non-breakable shell in core and a future provider of /bin/sh. But
> the latter wasn't implemented yet and no other package depends on it. So I
> guess we could safely remove it from core/base and add it to extra.

Well since we have been busted as hell at requiring scripts to be
strictly sh-compatible, this hasn't been able to slip in as our
default sh (even something Ubuntu could pull off). I guess I don't
care what you guys want to do with it since no one really cares about
having a fast and stable sh interpreter; I gave up on this pursuit a
while back as no one else seemed interested.

-Dan
 
Old 05-18-2010, 05:40 AM
Allan McRae
 
Default dash 0.5.6-1

On 18/05/10 14:28, Dan McGee wrote:

On Sun, May 16, 2010 at 4:58 AM, Pierre Schmitz<pierre@archlinux.de> wrote:

On Sat, 15 May 2010 15:48:46 +1000, Allan McRae<allan@archlinux.org>
wrote:

On 15/05/10 12:09, Dan McGee wrote:

Signoff both architectures, new-ish upstream version. We no longer
build statically with klibc since it doesn't exist; instead this is
linked against glibc. It is still super lightweight though.


Signoff both.

Although... given this is no longer statically linked, does this need
to stay in the base group, or even [core]?


Good question. I had to look it up: Dan introduced the dash package to
have a non-breakable shell in core and a future provider of /bin/sh. But
the latter wasn't implemented yet and no other package depends on it. So I
guess we could safely remove it from core/base and add it to extra.


Well since we have been busted as hell at requiring scripts to be
strictly sh-compatible, this hasn't been able to slip in as our
default sh (even something Ubuntu could pull off). I guess I don't
care what you guys want to do with it since no one really cares about
having a fast and stable sh interpreter; I gave up on this pursuit a
while back as no one else seemed interested.


Well, if we eventually want dash as /bin/sh, then it definitely needs to
stay in [core].


Is there a bug report/wiki page or anything detailing what we need to do
to make that change? It has been so long since this was brought up, I
have forgotten what has and has not been done.


Allan
 
Old 05-18-2010, 01:36 PM
Dan McGee
 
Default dash 0.5.6-1

On Tue, May 18, 2010 at 12:40 AM, Allan McRae <allan@archlinux.org> wrote:
> On 18/05/10 14:28, Dan McGee wrote:
>>
>> On Sun, May 16, 2010 at 4:58 AM, Pierre Schmitz<pierre@archlinux.de>
>> *wrote:
>>>
>>> On Sat, 15 May 2010 15:48:46 +1000, Allan McRae<allan@archlinux.org>
>>> wrote:
>>>>
>>>> On 15/05/10 12:09, Dan McGee wrote:
>>>>>
>>>>> Signoff both architectures, new-ish upstream version. We no longer
>>>>> build statically with klibc since it doesn't exist; instead this is
>>>>> linked against glibc. It is still super lightweight though.
>>>>
>>>> Signoff both.
>>>>
>>>> Although... * given this is no longer statically linked, does this need
>>>> to stay in the base group, or even [core]?
>>>
>>> Good question. I had to look it up: Dan introduced the dash package to
>>> have a non-breakable shell in core and a future provider of /bin/sh. But
>>> the latter wasn't implemented yet and no other package depends on it. So
>>> I
>>> guess we could safely remove it from core/base and add it to extra.
>>
>> Well since we have been busted as hell at requiring scripts to be
>> strictly sh-compatible, this hasn't been able to slip in as our
>> default sh (even something Ubuntu could pull off). I guess I don't
>> care what you guys want to do with it since no one really cares about
>> having a fast and stable sh interpreter; I gave up on this pursuit a
>> while back as no one else seemed interested.
>
> Well, if we eventually want dash as /bin/sh, then it definitely needs to
> stay in [core].
>
> Is there a bug report/wiki page or anything detailing what we need to do to
> make that change? *It has been so long since this was brought up, I have
> forgotten what has and has not been done.

* http://mailman.archlinux.org/pipermail/arch-dev-public/2007-November/003053.html
* https://launchpad.net/ubuntu/+spec/dash-as-bin-sh
* https://wiki.ubuntu.com/DashAsBinSh
* All install scripts must be sh-compatible (or we need a way of
executing non-sh scripts, there is a bug open for that)
* Any daemon/init script is probably written for /bin/bash as our
rc.conf and other initscripts files use bash arrays, so those need to
be pointed correctly

I think it is something like that. We should probably drop this into a
wiki page; I also know there have been various pushes from within the
community that seem to have been snuffed out along the way as well.

-Dan
 
Old 05-28-2010, 08:57 AM
Pierre Schmitz
 
Default dash 0.5.6-1

On Tue, 18 May 2010 08:36:16 -0500, Dan McGee <dpmcgee@gmail.com> wrote:
>> Well, if we eventually want dash as /bin/sh, then it definitely needs
to
>> stay in [core].
>>
>> Is there a bug report/wiki page or anything detailing what we need to
do
>> to
>> make that change? *It has been so long since this was brought up, I
have
>> forgotten what has and has not been done.
>
> *
>
http://mailman.archlinux.org/pipermail/arch-dev-public/2007-November/003053.html
> * https://launchpad.net/ubuntu/+spec/dash-as-bin-sh
> * https://wiki.ubuntu.com/DashAsBinSh
> * All install scripts must be sh-compatible (or we need a way of
> executing non-sh scripts, there is a bug open for that)
> * Any daemon/init script is probably written for /bin/bash as our
> rc.conf and other initscripts files use bash arrays, so those need to
> be pointed correctly

I would say make sure that core packages are fine with /bin/sh being dash
and then move it to testing. This should speed up things. For the install
scripts: why can't pacman just call /bin/bash? I mean makpekg and the
PKGBUILDS need bash anyway.

--
Pierre Schmitz, https://users.archlinux.de/~pierre
 
Old 05-28-2010, 09:17 AM
Xavier Chantry
 
Default dash 0.5.6-1

On Fri, May 28, 2010 at 10:57 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
>
> I would say make sure that core packages are fine with /bin/sh being dash
> and then move it to testing. This should speed up things. For the install
> scripts: why can't pacman just call /bin/bash? I mean makpekg and the
> PKGBUILDS need bash anyway.
>

I think that the two pending patches from Jonathan Conder on my branch
http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=working
would make this cleaner and easier to do.
1) switch from popen to execl : popen implicitely calls /bin/sh, so
when we had /bin/sh=dash and wants bash, it would call /bin/dash then
/bin/bash. But execl gives us more control.
2) ldconfig is now called directly so if we do the change /bin/sh ->
/bin/bash, it only affects scriptlet executions.

But I am pretty sure we talked about this before, maybe there was a
bug report, and some people suggested to make the shell path
configurable.
Thinking about it now, I would be fine with just calling /bin/bash
directly. If we consider pacman project as a whole, it's pretty much
tied to bash anyway.
 
Old 05-28-2010, 11:09 AM
Nezmer
 
Default dash 0.5.6-1

On Fri, May 28, 2010 at 11:17:49AM +0200, Xavier Chantry wrote:
> On Fri, May 28, 2010 at 10:57 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
> >
> > I would say make sure that core packages are fine with /bin/sh being dash
> > and then move it to testing. This should speed up things. For the install
> > scripts: why can't pacman just call /bin/bash? I mean makpekg and the
> > PKGBUILDS need bash anyway.
> >
>
> I think that the two pending patches from Jonathan Conder on my branch
> http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=working
> would make this cleaner and easier to do.
> 1) switch from popen to execl : popen implicitely calls /bin/sh, so
> when we had /bin/sh=dash and wants bash, it would call /bin/dash then
> /bin/bash. But execl gives us more control.
> 2) ldconfig is now called directly so if we do the change /bin/sh ->
> /bin/bash, it only affects scriptlet executions.
>
> But I am pretty sure we talked about this before, maybe there was a
> bug report, and some people suggested to make the shell path
> configurable.
> Thinking about it now, I would be fine with just calling /bin/bash
> directly. If we consider pacman project as a whole, it's pretty much
> tied to bash anyway.
>

+1 from someone who is using pacman in a FreeBSD environment. Where
"/bin/sh" is linked to neither bash nor dash.

bash is used in both makepkg and repo-add. It's not a platform-dependent
terrible dependency. And for recovery purposes, It can optionally be built
statically. The static option is actually supported as a configure flag.
 
Old 05-28-2010, 10:20 PM
Allan McRae
 
Default dash 0.5.6-1

On 28/05/10 21:09, Nezmer wrote:

On Fri, May 28, 2010 at 11:17:49AM +0200, Xavier Chantry wrote:

On Fri, May 28, 2010 at 10:57 AM, Pierre Schmitz<pierre@archlinux.de> wrote:


I would say make sure that core packages are fine with /bin/sh being dash
and then move it to testing. This should speed up things. For the install
scripts: why can't pacman just call /bin/bash? I mean makpekg and the
PKGBUILDS need bash anyway.



I think that the two pending patches from Jonathan Conder on my branch
http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=working
would make this cleaner and easier to do.
1) switch from popen to execl : popen implicitely calls /bin/sh, so
when we had /bin/sh=dash and wants bash, it would call /bin/dash then
/bin/bash. But execl gives us more control.
2) ldconfig is now called directly so if we do the change /bin/sh ->
/bin/bash, it only affects scriptlet executions.

But I am pretty sure we talked about this before, maybe there was a
bug report, and some people suggested to make the shell path
configurable.
Thinking about it now, I would be fine with just calling /bin/bash
directly. If we consider pacman project as a whole, it's pretty much
tied to bash anyway.



+1 from someone who is using pacman in a FreeBSD environment. Where
"/bin/sh" is linked to neither bash nor dash.

bash is used in both makepkg and repo-add. It's not a platform-dependent
terrible dependency. And for recovery purposes, It can optionally be built
statically. The static option is actually supported as a configure flag.



People who use pacman do not necessarily use makepkg or repo-add so
using that as a basis for hard coding /bin/bash is wrong.


Dan and I have discussed allowing a #! at the top of install scripts. I
think he had some very draft code that even allowed python scriptlets!


Allan
 

Thread Tools




All times are GMT. The time now is 06:45 AM.

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