Le mercredi 15 avril 2009 à 23:05 -0500, Manoj Srivastava a écrit :
So, no, policy does not just document current practice. Policy
tries to document what is right.
I think it should be both. When we do things right, they should be
specified in the Policy, and there’s no point
Le mercredi 15 avril 2009 à 17:12 -0500, Raphael Geissert a écrit :
Then there must be some sort of missunderstanding. My intention was not to
troll, but to demonstrate the implications of what you said. I would like
to apologise for my previous message as I had understood something
completely
On Thu, Apr 16 2009, Josselin Mouette wrote:
Le mercredi 15 avril 2009 à 23:05 -0500, Manoj Srivastava a écrit :
So, no, policy does not just document current practice. Policy
tries to document what is right.
I think it should be both. When we do things right, they should be
Le mardi 14 avril 2009 à 18:45 -0500, Raphael Geissert a écrit :
what feature provided by dash is being deprecated?
Like Russ said, if there's any feature not covered by policy that is
reasonable to be required please say so.
It is not the role of the policy to specify the exact requirements
Josselin Mouette j...@debian.org writes:
It is not the role of the policy to specify the exact requirements of
the /bin/sh implementation.
It is, however, the role of Policy to specify the minimum required feature
set that all scripts can assume.
Actually it would be better to specify that
Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit :
Actually it would be better to specify that scripts must work with both
sh implementations available in Debian, being bash and dash, rather than
making nothing more than a fork of the POSIX spec.
The advantage of the current
Josselin Mouette wrote:
Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit :
Actually it would be better to specify that scripts must work with both
sh implementations available in Debian, being bash and dash, rather
than making nothing more than a fork of the POSIX spec.
The
Le mercredi 15 avril 2009 à 11:44 -0500, Raphael Geissert a écrit :
Policy documents practice. When that new /bin/sh exists, you can change
bash is the current /bin/sh, from your statements I could imply that we
should require all /bin/sh's to support: b0rken bash arrrays, shell
regexes!,
Josselin Mouette j...@debian.org writes:
Le mercredi 15 avril 2009 à 02:16 -0700, Russ Allbery a écrit :
The advantage of the current Policy approach is that we have some hope
of introducing a new /bin/sh down the road, and we don't require that
packages comply with bugs in dash that should
Josselin Mouette wrote:
Le mercredi 15 avril 2009 à 11:44 -0500, Raphael Geissert a écrit :
[...]
And taking your statement to the extreme, it means that if zsh was used
as /bin/sh then no other shell interpreter could ever be used as /bin/sh
ever again but a fork of zsh.
I’m proposing
On Wed, Apr 15 2009, Josselin Mouette wrote:
Policy documents practice.
I wish people would not say that. It is not true; and hasn't
been. And, moreover, we would not _want_ that to be true; there should
be no excuse to justify wanting to enshrine broken or bad practices
into policy.
On Sun, Apr 12, 2009 at 09:35:37PM +0200, Marco d'Itri wrote:
* Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
local and a few other directives for no good reason but at a huge cost.
Beside local per se, what is exactly the problem? If you badly
On Apr 14, Stefano Zacchiroli z...@debian.org wrote:
Beside local per se, what is exactly the problem? If you badly need
bash-specific features you can use /bin/bash as the interpreter.
Every deviation from upstream has a cost, which needs to be justified
by a cost-benefits analisys.
The point
Marco d'Itri wrote:
[...]
The point is not to eliminate bashism but dashism, and so far there are
no demonstrated benefits to deprecating features available in dash but
not in posh.
what feature provided by dash is being deprecated?
Like Russ said, if there's any feature not covered by policy
On Apr 15, Raphael Geissert atomo64+deb...@gmail.com wrote:
what feature provided by dash is being deprecated?
You are the one who started the thread. Please come back when you will
actually know what you are proposing exactly.
Like Russ said, if there's any feature not covered by policy that
Hello everyone,
I would like to propose the following Release Goals for squeeze:
* Dash as default /bin/sh
A lot of work was done on this RG already for lenny but, sadly, it didn't make
it. Further improvements to checkbashisms as well as support for checking for
bashisms in all /bin/sh and
On Apr 12, Raphael Geissert atom...@gmail.com wrote:
* Dash as default /bin/sh
This is good.
* Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
local and a few other directives for no good reason but at a huge cost.
needed to support dash as
m...@linux.it (Marco d'Itri) writes:
On Apr 12, Raphael Geissert atom...@gmail.com wrote:
* Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
local and a few other directives for no good reason but at a huge
cost.
No, he's not -- look at the
On Sun, Apr 12, 2009 at 09:35:37PM +0200, Marco d'Itri wrote:
* Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
local and a few other directives for no good reason but at a huge cost.
Policy specifically states that use of local is permitted
On Apr 12, Roberto C. Sánchez robe...@connexer.com wrote:
Policy specifically states that use of local is permitted [0]:
So exactly what do you want to disallow which is supported by dash but
not by policy, and for which purpose?
--
ciao,
Marco
signature.asc
Description: Digital signature
Marco d'Itri wrote:
On Apr 12, Roberto C. Sánchez robe...@connexer.com wrote:
Policy specifically states that use of local is permitted [0]:
So exactly what do you want to disallow which is supported by dash but
not by policy, and for which purpose?
I don't have a list at hand (I do have
On Apr 12, Raphael Geissert atomo64+deb...@gmail.com wrote:
I don't have a list at hand (I do have a sort of list in another machine
which is unreachable atm); but the first one that comes to my mind is the
use of 'type', it's output is unreliable and in some shell interpreters it
is not
Marco d'Itri wrote:
On Apr 12, Raphael Geissert atomo64+deb...@gmail.com wrote:
I don't have a list at hand (I do have a sort of list in another machine
which is unreachable atm); but the first one that comes to my mind is the
use of 'type', it's output is unreliable and in some shell
23 matches
Mail list logo
