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

[Goswin von Brederlow]

Philipp Kern  writes:

> On 2009-07-25, Goswin von Brederlow  wrote:
>> The existing dash package uses dpkg-divert, which is unsuitable on a
>> larger scale (larger than the one dash package). And to have bash
>> removable dash has to force itself as /bin/sh. So there goes even that
>> little choice.
>>
>> What alternative do you speak off where the user will have a choice of
>> what is /bin/sh?
>
> I don't see us supporting anything else than dash and bash for /bin/sh
> for squeeze.  So the current solution is acceptable.  You can try to
> prove me wrong, of course.  But someone would need to collect the
> falling out pieces when /bin/sh is switched to something they want
> to see supported (and commit to that).

But can you see that some other option would be possible in the
future? That someone might want to try something else as /bin/sh and
start fixing the bugs that causes?

I do feel that that is a possibility and we should not go from being
locked into bash being essential and /bin/sh to being locked into dash
being essential and /bin/sh. That is what it is all about.

> zsh is certainly not suitable for /bin/sh, sorry.
>
> Kind regards,
> Philipp Kern
>
> PS: I do use zsh as user shell, though and would like to thank for his
> work on that. ;-)

Never said it would. Doubt it will be in the near future. Far more
likely would be posh or busybox. But you never know.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching /bin/sh to dash (part two)

[Peter Samuelson]

[Bernd Eckenfels]
> >>   if [ -n "$idl" ] && [ -x $idl ]; then
> 
> This misses quotes.

So, how many unsafe characters do _you_ see in the following service
names?

apache2-common at bayonne cherokee courier-authdaemon cron cups
dante-server diald dovecot-common exim exim4-base fcron
fireflier-server freeradius gdm heartbeat heartbeat-2
hylafax-server iiimf-server inn2 kannel linesrv linesrv-mysql
lsh-server muddleftpd netatalk nuauth partimage-server perdition
pgpool popa3d postgresql-7.4 postgresql-8.1 postgresql-8.2 proftpd
pure-ftpd pure-ftpd-ldap pure-ftpd-mysql pure-ftpd-postgresql
racoon samba sasl2-bin sfs-server solid-pop3d squid squid3 tac-plus
vsftpd wu-ftpd wzdftpd xrdp yardradius yaws
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#538202: ITP: virt-what -- detect if we are running in a virtual machine

[Joe Smith]

"Manoj Srivastava"  wrote:

Virt-what is more accurate than Imvirt, version 1.0 can tell the
difference between Xen Dom0 and DomU. The new version (1.1, released
on 23 july 2009) can tell the difference between QEMU and KVM, and can
tell if you are running inside a Xen fullvirt guest.


   This sounds cool. Does it support user-mode-linux as well?


At the moment, it can detect VMWare, Microsoft Versions of Virtual PC, 
OpenVZ, Xen-HVM, Xen-DomU, Xen-Dom0, KVM, and QEMU.


I'm betting the author would be willing to incorporate checks for other 
systems if they can be easilly done in a bash script.





--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Philipp Kern]

On 2009-07-25, Goswin von Brederlow  wrote:
> The existing dash package uses dpkg-divert, which is unsuitable on a
> larger scale (larger than the one dash package). And to have bash
> removable dash has to force itself as /bin/sh. So there goes even that
> little choice.
>
> What alternative do you speak off where the user will have a choice of
> what is /bin/sh?

I don't see us supporting anything else than dash and bash for /bin/sh
for squeeze.  So the current solution is acceptable.  You can try to
prove me wrong, of course.  But someone would need to collect the
falling out pieces when /bin/sh is switched to something they want
to see supported (and commit to that).

zsh is certainly not suitable for /bin/sh, sorry.

Kind regards,
Philipp Kern

PS: I do use zsh as user shell, though and would like to thank for his
work on that. ;-)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Better tracebacks for C/C++ (and probably Ada & Fortran, too)

[Florian Weimer]

I've built a small proof-of-concept library which creates Java-style
tracebacks for C and C++ programs.  In contrast to libc's backtrace()
function, it uses DWARF debugging information when available, so the
output is generally quite useful.  Debugging information is extracted
from the main executable and any loaded DSOs, or from the shadow debug
tree in /usr/lib/debug.

The whole thing is a bit of a mess because it links together ld.so,
libgcc's unwinder, libdwarf and the demangler from libiberty.  The
advantage is that it should work with anything which generates stack
frames compatible with _Unwind_Backtrace() (which likely includes all
architectures for which we've got GCJ support) and DWARF debugging
information.  No additional compiler-generated tables or special
exception calsses are needed, so it generally works out of the box
(provided you compile with "-g").  This is in contrast to stack
tracebacks in GCJ; the downside is that my implementation is quite a
bit slower, but unlike Java, it's only called when there is actually
an unhandled exception which is about to terminate the program (Java
creates a backtrace each time a throwable object is initialized).

Some clean-up is still needed (mainly to make it more robust with
questionable DWARF data, e.g. in the presence of circular debugging
information).

I'm now wondering whether something like this already exists (I
couldn't find anything, though).  I'm also not sure where to put this.
Due to the peculiar combination of libraries, it's somewhat
Debian-specific.

The output currently looks like this, and is recognized by Emacs:

Exception std::runtime_error: foo
at test_traceback(test/test-traceback.cpp:18)
at main(build/test/run.cpp:13)
at 
__libc_start_main(/home/aurel32/tmp/eglibc/eglibc-2.9/csu/libc-start.c:222)
at (../sysdeps/x86_64/elf/start.S:113)

SIGBUS/SIGSEGV could probably handled in a similar way, but the bulk
of the work should probably done in a fresh subprocess, with
uncorrupted data structures.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Debian, universal operating system?

[Frank Lin PIAT]

## BANNER { http://www.debian.org/banners/3.1/sarge-ban1-6.png }

Universal operating system #...@!

First of all, let's make it clear, Debian is not THE universal operating
system. I mean it is definitely not the one and only OS.


Is Debian an universal operating system?

Before answering this question, we need to define what would it means to
be an universal OS?

Does it mean that in runs many architecture?
 yes, Debian support a dozen of them, of all kinds.

Does it means that it can run on different type of platforms? 
 yes, Debian can run on mainframes, on clusters, servers, desktop,
 laptop, palmtop, embedded system, telephones and probably on
 some "nailtop" some days.

Does it means that it provides a wide range of applications for a
wide range of customers?
 yes, Debian probably provides applications for any purpose you 
 can think of. Well, may be not all of them yet.

Does it means that it ships many software for the same purpose, to fit
various needs?
 yes, Debian provides dozens of webservers, database, CMS,
 wordprocessing... some tiny and simple, some large with rich set of
 features, etc (But don't worry, Debian can choose a default one for
  you)

Does it means Debian runs run various kernels?
 yes, Debian provides support for Linux and we may soon provide 
 support for GNU/kFreeBSD. There are other derivative works to support
 Darwin and OpenSolaris kernel.

Does it means that we support multiple user environment?
 yes, Debian provides 4 main Desktop environment (KDE, XFCE, LXDE and
 the default one Gnome). It also has some user interface for other 
 type of device, like Hildon for embedded devices.

But it certainly doesn't means that all the packages and all the
features must be available on all the above variants. It doesn't make
sense to run a DVD player on a mobile phone or on a mainframe. It
doesn't make sense to do massive parallel computation on a tiny embedded
devices. 

Does it means that Debian is a commodity thing?
 no, Debian is a very specialized OS, which specific positioning IS to
 be universal. (Not to mention that it's free as in [free beer|freedom],
 open-source, community-driven, etc)


Why many Debian users and Developers are really happy with this Univeral
OS concept?

Well I suppose it has do with our social contract and the DFSG.

That's what I like in Debian(1),

Franklin



Side note about derivative distributions.
Yes, any one is allowed to fork Debian and make a derivative
distribution, and that's fine, I like that.

All of these forks have one thing in common: they have a different
specialization than Debian. Some are specialized for a specific
language, for end-user, for embedded, for palmtops, for a given kernel,
for a special field of endeavor, etc. Of course, those distributions put
lots of effort in their specialized domain and they are well ahead of
us. Some of those distribution are very successful and it is great,
because it is also our success.
Because we live in open-source world, most of them are merging their
patch, so we progress as quickly as them (even if we are "lagging")

In the end, it's the whole open-source ecosystem that grows quickly, and
that's great.


(1) I like that I am free to use Debian on my Laptop, on my PS3, on my
Nokia N810, on my wireless access point or NAS device. My
organisation could use the same OS on it a mainframe, on clusters,
on computers, on desktops, on smart phones. One single OS that can
be adapted for each use.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Whence /usr/lib/debug?

[Florian Weimer]

* Russ Allbery:

> Policy should definitely describe what to do here.  I don't know enough
> about the toolchain to know what Policy should say, but we should
> standardize how to handle debug packages at this point, since we have a
> fairly standard way of handling it now.

If we could standardize on this, that would be fine with me:

  Separate debug information objects [name?] must be installed under
  /usr/lib/debug.  The file name must be the result of calling
  realpath() on the path to the actual DSO containing code, prepended
  with the string "/usr/lib/debug".  Separate debug information
  objects must not be provided for static libraries under
  /usr/lib/debug.

libstdc++6-4.3-dbg does not currently follow this, which prompted me
to write this message:

libstdc++6-4.3-dbg: /usr/lib/debug/libstdc++.a
libstdc++6-4.3-dbg: /usr/lib/debug/libstdc++.so
libstdc++6-4.3-dbg: /usr/lib/debug/libstdc++.so.6
libstdc++6-4.3-dbg: /usr/lib/debug/libstdc++.so.6.0.10

This is already a bug today because GDB can't find the objects (and my
code can't find them, either).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

An introduction to multiarch

[Goswin von Brederlow]

Hi,

after listening to the "Multiarch round table" talk at Debconf I feel
that the talk was targeted at people already familiar with the subject
and jumped right in at full speed. Someone new to the idea was
probably lost in the first minute.

So I decided to write an introduction to the problem that focuses more
on the user side, why we want multiarch at all, what goals and
requirements are to be met and gives some pointers. I leave the
techincal details to the actual proposal. Hopefully that helps more
people to jump on the wagon and help. Note that this is to be taken
together with the proposal itself:

  https://wiki.ubuntu.com/MultiarchSpec

Steve, please take a look at the pointers section 2 and 3 below for
things diverging from the wiki.


So here goes nothing:

An introduction to multiarch


What do we have currently?
--

Most architectures in Debian (all but alpha) are capable of executing
binaries compiled for different ABIs (Aplication Binary Interface).
The difference can be the 32bit or 64bit instruction sets as present
on amd64 / emt64 CPUs.

Now we face the problem that some software is only available for some
ABIs. For example wine only runs in 32bit mode as it emulates the win32
ABI or Google Earth is only available in 32bit. So while nearly all of
the amd64 packages are 64bit some need to be 32bit or are only
available in 32bit.

The solution to that currently is bi-/tri-arch packages. That means
that libraries are build on one architecture for multiple ABIs. The is
a libbz2 package, a lib32bz2 and a lib64bz2 package. The later two are
compiled using /usr/lib32 and /usr/lib64 as libdir respectively. This
has some major drawbacks:

1) Bi-/tri-arch is limited to exactly those 2/3 ABIs.
2) Libraries need to be compiled multiple times with special cases for
   each architecture depending on what ABIs each architecture has.
3) Only a verry few libs are compiled bi-/tri-arch. The majority of
   32bit libraries needed on amd64 come out of the ia32-libs /
   ia32-apt-get hacks which is verry verry ugly.


Where do we want to go? What is the goal of multiarch?
--

Overall multiarch tries to unify sveral different use cases into a
straight forward and simple solution avoiding special casing
architectures or multiple compilations.

- On amd64 we want to be able to install libraries and binaries from
  i386 (32bit) and amd64 (64bit). E.g. run wine or google earth.

- On hppa, sparc, mips, mipsel, powepc and s390 we want to be able to
  install 32bit for most things but also 64bit packages for some
  special cases where a 64bit address space or 64bit registers
  outweigh the cost of the larger instruction set and pointers.
  E.g. run a 64bit postgresql using >4GB ram.

- For embedded use we want to be able to install arm libraries on for
  example amd64 and cross-compile packages.

- On kFreeBSD we want to be able to install Linux binaries.

- For fun we want to be able to install ppc binaries on mips and run
  them with qemu.


Design goals and requirements:
--

The current proposal fullfills the following goals and requirements:

- library packages from multiple architectures must be installable at
  the same time
- binaries must be installable from multiple architectures but one at
  a time is sufficient
- new debs must work on old Debian (for the one architecture)
- old debs must work on new Debian, esspecially 3rd party ones
- only change what must
- switching to multiarch must work in increments, idealy deb by deb
- dependencies must track where a matching ABI is required and where
  the ABI is inconsequential.

Those garanty a smooth transition from uni-arch to multi-arch.

The following goal is delayed for a later time to get the ball rolling
but nothing in the proposal actualy stands in the way of it. It is
just left out as a time saver for the start.

- Developement packages from multiple architectures must be
  installable at the same time. This is important for cross-compiling.


The multiarch proposal (some pointers)
--

Please read the multiarch specs in parallel. The below is ment as
helpfull hints acompaning the specs. The full multiarch specs can be
found on: https://wiki.ubuntu.com/MultiarchSpec

The proposal contains 4 major points:

1) Filesystem layout

For library packages from multiple architectures to be installable at
the same time there can be no files in the same location for different
architectures. On each architecture the location of files must be
unique. The choosen unqiue identifier in the proposal is the GNU
triplet (DEB_HOST_GNU_TYPE). This is unique for each Debian
architecture and even for things not (yet) in Debian like building
against uclibc.

The GNU triplet is introduced for every arch and it is always the
$(DEB_HOST_GNU_TYPE). There is no special casing to figure out the
--libdir setting for a 

Re: Whence /usr/lib/debug?

[Russ Allbery]

Florian Weimer  writes:

> Where does the convention for this directory hierarchy come from?  There
> are several different naming conventions for the debug objects stored
> there, and I wonder if some of them are bugs.  (If the wrong file name
> or path is used, debuggers will have a hard time discovering debugging
> symbols.)
>
> Should Policy describe what to do here?

Policy should definitely describe what to do here.  I don't know enough
about the toolchain to know what Policy should say, but we should
standardize how to handle debug packages at this point, since we have a
fairly standard way of handling it now.

Whatever Policy says should also address when it's appropriate to ship a
debugging build of the library instead of detached debugging symbols (if,
for instance, a debugging build changes the code to add additional
instrumentation that's useful).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Whence /usr/lib/debug?

[Florian Weimer]

Where does the convention for this directory hierarchy come from?
There are several different naming conventions for the debug objects
stored there, and I wonder if some of them are bugs.  (If the wrong
file name or path is used, debuggers will have a hard time discovering
debugging symbols.)

Should Policy describe what to do here?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Goswin von Brederlow]

Raphael Geissert  writes:

> Goswin von Brederlow wrote:
>> But that should be a choice. Not forced upon the user. As Manoj has
>> said now a few times, many things will break for users even if all of
>> Debian is dash fixed. By making /bin/sh choosable everybody wins.
>> 
>
> Who said anything about not offering the user to choose what /bin/sh points
> to?
> Nobody.
>
> Cheers,
> Raphael Geissert

Then where is that choice? How will it be done?

The proposal has shown one way of doing it.

The existing dash package uses dpkg-divert, which is unsuitable on a
larger scale (larger than the one dash package). And to have bash
removable dash has to force itself as /bin/sh. So there goes even that
little choice.

What alternative do you speak off where the user will have a choice of
what is /bin/sh?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Goswin von Brederlow]

Gabor Gombas  writes:

> On Fri, Jul 24, 2009 at 06:31:59PM +0200, Goswin von Brederlow wrote:
>
>> Why would you think the one transition would be helpfull in the second
>> or that there would be less breakage in the second if we do the first
>> one first? I would rather say you are doubling the problems and
>> breakages as the two are completly different mechanisms.
>
> Making the shell selectable means more code than hardcoding a single
> string. More code means more bugs. Since a bug in this case can result
> in an unbootable system, doing things one step at a time so you only
> have to look for bugs in one component at a time makes perfect sense
> IMHO.
>
> Gabor

But having the string hardcoded to /bin/bash or to /bin/dash makes
absolutely no difference later when it comes to making it selectable.
You get exactly the same bugs then and you also get the bugs now for
changing the hardcoded string.

It is not doing things a step at a time. It is taking one step to the
right and then taking a step forward. Steping to the right first
doesn't move you forward at all.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#538406: ITP: libparse-win32registry-perl -- a module for parsing Windows Registry files

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: libparse-win32registry-perl
  Version : 0.50-1
  Upstream Author : James Macfarlane 
* URL or Web page : http://search.cpan.org/dist/Parse-Win32Registry/
* License : Perl (Artistic | GPL)
  Description : a module for parsing Windows Registry files



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching /bin/sh to dash (part two)

[Bernd Eckenfels]

In article <2qrqj6-973@argenau.downhill.at.eu.org> you wrote:
>>   if [ -n "$idl" ] && [ -x $idl ]; then

This misses quotes.

Greetings
Bernd


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#538389: ITP: rfkill -- tool for enabling and disabling wireless devices

[Darren Salt]

Package: wnpp
Severity: wishlist
Owner: Darren Salt 

* Package name: rfkill
  Version : 0.1-4-g9429740
  Upstream Authors: Johannes Berg, Marcel Holtmann, Tim Gardner
* URL : http://wireless.kernel.org/en/users/Documentation/rfkill
* Licence : BSD-style single-clause
  Programming lang: C
  Description : tool for enabling and disabling wireless devices

 rfkill is a simple tool for accessing the Linux rfkill device interface,
 which is used to enable and disable wireless networking devices, typically
 WLAN, Bluetooth and mobile broadband.
 .
 rfkill uses /dev/rfkill, which is present in Linux kernel 2.6.31 and later.


I'm choosing a git snapshot over 0.1 because it contains some functionality
which will be of use in eeepc-acpi-scripts.

-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | Army
|   Let's keep the pound sterling

I can't reach the brakes on this piano!



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching /bin/sh to dash (part two)

[Raphael Geissert]

Giacomo Catenazzi wrote:

> 
> Or telling bash (and shells in general) via some environment variable,
> that we are shutting down things.  Not clean, but I think the init
> could provide some extra informations.
> 

There are a couple of variables begin set by the rc script, but I don't
think bash should rely on variables to define behaviour in such a way.

Cheers,
Raphael Geissert




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Raphael Geissert]

Goswin von Brederlow wrote:
> But that should be a choice. Not forced upon the user. As Manoj has
> said now a few times, many things will break for users even if all of
> Debian is dash fixed. By making /bin/sh choosable everybody wins.
> 

Who said anything about not offering the user to choose what /bin/sh points
to?
Nobody.

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Vincent Lefevre]

On 2009-07-25 09:53:06 +0200, Steve Langasek wrote:
> On Fri, Jul 24, 2009 at 10:38:51AM -0500, Manoj Srivastava wrote:
> > On Fri, Jul 24 2009, Steve Langasek wrote:
> > > What's the advantage of having it be zsh? Is zsh faster than
> > > dash? Or is the only savings the elimination of the 84k dash
> > > binary from /bin?
> 
> > It allows all the #!/bin/sh scripts that us zsh-isms to run.
> 
> They can already be run under #!/bin/zsh. Why would we want to tie
> our hands even further as a distribution by putting ourselves in the
> position of having end users deploying /bin/sh scripts that require
> zsh, *in addition* to the end users who already deploy /bin/sh
> scripts that require bash?

I don't know what Manoj had in mind exactly, but he hasn't said that
zsh would be required. Think about something like that:

#!/bin/sh
if test -n "$ZSH_VERSION"; then
  foo="$HOME:t"
else
  foo="..."  <- slower version for generic POSIX shells
fi

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching /bin/sh to dash (part two)

[Andreas Metzler]

Clint Adams  wrote:
[...]
> The second hunk isn't relevant to bash, but it seems a waste to
> call ls and head for no reason.

> --- debian/libpam0g.postinst.orig   2009-07-24 08:59:07.0 -0500
> +++ debian/libpam0g.postinst2009-07-24 09:00:38.0 -0500
> @@ -1,4 +1,4 @@
> -#!/bin/bash
> +#!/bin/sh

> # postinst based heavily on the postinst of libssl0.9.8, courtesy of 
> # Christoph Martin.
> @@ -73,7 +73,7 @@

> for service in $check; do
>if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
> -  idl=$(ls /etc/init.d/${service} 2> /dev/null | head -n 1)
> +  idl="/etc/init.d/${service}"
>   if [ -n "$idl" ] && [ -x $idl ]; then
>services="$service $services"
>   else


Hello,

FWIW the $(...) construct is not a bashism.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: shells and posix compliance [was Re: Switching /bin/sh to dash without dash essential]

[Giacomo Catenazzi]

Clint Adams wrote:

[not replying off-list because that seems counterproductive and arrogant]

On Fri, Jul 24, 2009 at 03:49:15PM +, brian m. carlson wrote:

Actually, if it's invoked as /bin/sh, it is supposed to be
Bourne-compatible.  That's my experience with the current version:


Not much effort is put into strict POSIX compliance, though people
certainly do complain about it[1].


I don't know what other versions do.  I'm working on finding bugs with
zsh as /bin/sh; see #510358.  If anyone knows about a good /bin/sh
(POSIX, XSI, or Debian) testsuite, please let me know off-list.


I'd certainly welcome improvements to the posh testsuite to that end.
Run the harness with category 'debian' or 'posix' depending on which
"standard" you're going for.


BTW Linux is not POSIX. Linux (LSB) has few incompatible rules.
Check the join working document austin (POSIX) and LSB:

http://www.opengroup.org/platform/single_unix_specification/doc.tpl?CALLER=index.tpl&gdid=13450

Personal opinion: it seems that linux will do some changes to be more
posix compatible, but for most of incompatibilities (IMHO) POSIX will 
change toward linux.


ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching /bin/sh to dash (part two)

[Giacomo Catenazzi]

Gabor Gombas wrote:

On Fri, Jul 24, 2009 at 06:39:53PM +0200, Giacomo Catenazzi wrote:


BTW it seems that all previous tries to remove the bug in bash failed.


Actually it's not a bug in bash at all. The bug is the combined effect
of how bash behaves and how the NSS functionality is implemented inside
glibc.

AFAIR "fixing" bash would make it incompatible with existing user
scripts. So it would have (almost) all of the drawbacks of the
bash->dash transition without none of the benefits.


Not necessarily, but also not easy to fix.
bash could wait until the first nss use to "connect" to libc nss.
This would also speed up bash for these users.

Or telling bash (and shells in general) via some environment variable,
that we are shutting down things.  Not clean, but I think the init
could provide some extra informations.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Fri, Jul 24, 2009 at 09:15:43PM +0200, Goswin von Brederlow wrote:
> And what if my posh is compiled against uclibc? You never know.
> For embedded systems that is not too far fetched.

The embedded system developers could just as easily build dash against
uclibc instead of posh.

Stop being difficult.  

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Fri, Jul 24, 2009 at 10:38:51AM -0500, Manoj Srivastava wrote:
> On Fri, Jul 24 2009, Steve Langasek wrote:

> > On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:

> >> I think you are not going far enough. Why should I have dash on
> >>  the system when my default shell is posh? or (gasp) zsh?

> > Why would you set your default shell to posh?  It's only marginally smaller
> > than dash, and my understanding is that it's slower.  It's more minimal from
> > a policy perspective, but I don't see that this is relevant for a live
> > Debian system.

> > What's the advantage of having it be zsh?  Is zsh faster than dash?  Or is
> > the only savings the elimination of the 84k dash binary from /bin?

> It allows all the #!/bin/sh scripts that us zsh-isms to run.

They can already be run under #!/bin/zsh.  Why would we want to tie our
hands even further as a distribution by putting ourselves in the position of
having end users deploying /bin/sh scripts that require zsh, *in addition*
to the end users who already deploy /bin/sh scripts that require bash?

> > And I think it has yet to be demonstrated that it's actually useful to
> > support all these other possible values of /bin/sh.  Without a concrete
> > reason why these configurations should be supported, generalizing the
> > implementation is needless overhead.

> Demonstrated to whom? You see, viability of alternatives has to
>  be demonstrated to the decision maker. My contention is that the Vendor
>  ought not to be the decision maker here, that the quality of
>  implementation of the OS improves if the system owner or custodian has
>  the ability to make that determination.

I propose to turn /usr/bin/make into an alternative so that Debian is not
robbing users of the ability to decide they want it to point to pmake.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Gabor Gombas]

On Fri, Jul 24, 2009 at 06:31:59PM +0200, Goswin von Brederlow wrote:

> Why would you think the one transition would be helpfull in the second
> or that there would be less breakage in the second if we do the first
> one first? I would rather say you are doubling the problems and
> breakages as the two are completly different mechanisms.

Making the shell selectable means more code than hardcoding a single
string. More code means more bugs. Since a bug in this case can result
in an unbootable system, doing things one step at a time so you only
have to look for bugs in one component at a time makes perfect sense
IMHO.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching /bin/sh to dash (part two)

[Gabor Gombas]

On Fri, Jul 24, 2009 at 06:39:53PM +0200, Giacomo Catenazzi wrote:

> BTW it seems that all previous tries to remove the bug in bash failed.

Actually it's not a bug in bash at all. The bug is the combined effect
of how bash behaves and how the NSS functionality is implemented inside
glibc.

AFAIR "fixing" bash would make it incompatible with existing user
scripts. So it would have (almost) all of the drawbacks of the
bash->dash transition without none of the benefits.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching /bin/sh to dash (part two)

[Gabor Gombas]

On Fri, Jul 24, 2009 at 06:17:30PM +0200, Goswin von Brederlow wrote:

> > Or we need to set explicitly use #!/bin/dash in umountall?
> > [not so flexible solution, but IMHO enough good]
> 
> If it needs dash then yes, set #!/bin/dash and Pre-Depend on dash.
> 
> But in this case that really needs to be fixed to work with any posix
> shell.

It's not the usual "umountall uses features not in POSIX" case but
rather "bash does lots of unneccessary things that in turn break
umountall". umountall wants a shell that does not do any NSS lookups
internally when it is not asked to. So it's bash that needs to be fixed
to do a lot less when it is invoked as /bin/sh.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org