> I don't see this as an acceptable resolution; programs or scripts > written to depend on coreutils may not run unless we supply these > utilities.
Isn't this true, though, of the omission of any component from coreutils? It's likely there are fewer programs that depend on coreutils' "su" or or even "shred" but we face the same issue with leaving those programs out as well. I don't know whether the LSB "standard" covers any of these components but in the absence of a GNU standards compliance requirement for OpenSolaris, it seems omitting certain items from coreutils is reasonable if not unavoidable (eg, for the security issues mentioned earlier.) In any case, I assume the unaltered GNU *sum utilities could still be shipped in /usr/gnu/bin even if the "native" ones proposed in PSARC/2005/530 were delivered in /usr/bin so a script requiring the coreutils' version would need to augment their PATH accordingly. (That said, I'm still uncomfortable with a ARC case that has reserved the name-space but not actually integrated anything preventing other projects from integrating an alternate implementation. Perhaps it just means that PSARC/2005/530 needs a follow-on case to include whatever changes necessary to be able to replace the coreutils versions.) dsc
