Marvin Renich <[EMAIL PROTECTED]> writes:
> * Jari Aalto <[EMAIL PROTECTED]> [061123 06:56]:
> >
> > But for the shells there are. I think the Policy should exempt shells
> > and require that if package is not POSIX/Susv -compiant, it needs to
> > announce dependance on a particular shell -- where it bash, tcsh,
> > pdksh ..., if it uses those shells special features.
> >
> > Jari
> >
>
> Making an exception like this is not a good idea, and is not necessary.
> If it is decided that allowing bash to be replaced by one of a short
> list of other shells is a good idea, then make each shell in the list
> Provide: almost-posix-shell (or something) and make almost-posix-shell
> essential (can a virtual package be essential?). Or make a real package
> almost-posix-shell that depends on bash | dash | ....
Russ, I'm CC'ing - please tell if you'd rather read the list.
I agree. Your suggestion solves this for all parties. The policy stays
intact, but the underlying dependencies need an improvement. The
problem I see in current situation is that
Packages' dependencies tend to be implicit. Sometimes it would
be more better to be explicit and not optimize dependencies away
with the assumption that a feature is provided by "essential".
In a way, Policy encourages view that listing explicit
dependencies is considered bad and wrong. On the contrary The
policy could encourage to make things transparent; this is good
testing and QA methodology. Policy should not care whether
package announces all dependencies or that some package
announces only those not covered in "essential".
The lack of explicit 'Depends:' is now shadowed byt the Policy which
does not require bash to be listed ... because it's in essential.
Your suggestion, that there should be something like:
Provides: standard-compliant-shell
in every shell packages that provide the standard (were it POSIX or
SusV) features expected in Debian. Even better, there should be a
test suite:
Package: standard-compliant-shell-test-suite
which could be used as measure to see which shells qualify the
"compliance"; whatever that would be.
A more simpler approach would be making /bin/dash the "test suite" and
suggesting developer's to test scripts under it. The dash could be
fixed to correct any non-standard features it might contain.
I'm not sure what's the deal with /bin/posh vs /bin/dash; but from
testing and QA perspective the more the marrier; if script passes
both, then it must be in good shape.
Jari
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
