[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PROPOSAL]drop LSB.usersgroups/commands/passwd/T.passwd 2



On Mon, Jul 30, 2001 at 11:20:35AM -0600, John H Terpstra wrote:
> On Mon, 30 Jul 2001, Andrew Josey wrote:
> > I agree also that the spec owners ought to consider an obsolescence path for
> > deprecating features. Some specifications I have worked on have
> > marked features as "To be withdrawn" for one version of the
> > specification prior to dropping a feature.
> Do we have such a process? If not we should put this on the agenda for a
> future discussion in the appropriate forum.

Because, hey, there's no better way to get things done than by making a
note on an agenda for a hypothetical meeting to have a discussion about
forumlating a policy for discussing future changes.

The usual way to handle removals of features is to just follow the same
process as adding features. As far as the LSB's concerned, this seems
to be discuss it on the phone, make the change in CVS and let people
comment later when a full RFC goes out.

Further, there seems to be some confusion as to what it means for the
LSB spec to test for a group password feature. What specifying it means
is that *every* LSB compliant system must support it, and that ISV's can
make use of it whenever they feel like it -- eg, lsbpkg --install foo.lsb
can create a new group, with a new password that might be hardcoded into
/opt/foo/bin/bar for some (bizarre) security regime. Not specifying it
means that LSB compliant systems may or may not support group passwords
as a local admin issue, and that LSB compliant packages are not allowed
to use them at all.

The LSB isn't about saying what admin's and distribution vendor's can and
can't do; merely what's going to be available for, and what's required
of, third party software packaged for Linux.

Or, at least, that was the answer I got when I asked on lsb-spec.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
                      -- John S. Novak, III (The Humblest Man on the Net)

Attachment: pgpYiJqZN9qci.pgp
Description: PGP signature


Reply to: