[lsb-discuss] /etc/profile.d and LSB (test procedure missing?)

Nick Stoughton nick at usenix.org
Mon Apr 9 10:56:53 PDT 2007


On Mon, 2007-04-09 at 17:33 +0100, Till Kamppeter wrote:
> <Mithrandir> it doesn't seem like "shall" is defined in the LSB spec.
> <Mithrandir> but they use shall and must. 

Let me deal with that one first, since it is the easiest!

LSB absolutely DOES define "shall". 

Chapter 4, definitions, says:
shall 

is to; is required to; it is required that; has to; only...is permitted;
it is necessary

Chapter 5, terminology, says:

"Other terms and definitions used in this document shall have the same
meaning as defined in Chapter 3 of the Base Definitions volume of ISO
POSIX (2003)." POSIX defines "shall" as:

shall
For an implementation that conforms to IEEE Std 1003.1-200x, describes a
feature or behavior that is mandatory. An application can rely on the
existence of the feature or behavior.

For an application or user, describes a behavior that is mandatory.

We do also use "must", though it is an undefined term. We should file a
bug to remove all uses of "must".


OK ... now to the meat of the problem ... I am the author of the words
in question, and they were discussed in a fair amount of detail at the
time we added them. We did review a number of implementations, and
requested feedback explicitly, knowing that it was a controversial area.
We received no feedback on either profile.d or sh -l. This was part of
the "lsbinstall" discussions ... and lsbinstall was deemed impossible to
reach consensus upon. So we needed to define ways to get around the
things we wanted lsbinstall for. Login actions was one of those. We
looked at what most distros were doing, and saw /etc/profile.d and login
-l were common, widespread practice. Now maybe we were wrong, but we did
think to add a "Future directions" note here to say that we felt this
was a temporary but adequate work-around to the issue at hand.

"Future Directions: These directories are required at this version of
the LSB since there is not yet an agreed method for abstracting the
implementation so that applications need not be aware of these locations
during installation. However, Future Directions describes a tool,
lsbinstall, that will make these directories implementation specific and
no longer required."

Mithrandir also says:
"And I think LSB is on  crack there, since they can't mandate changes to
what POSIX sh should support."

Absolutely the LSB can mandate extensions to POSIX behavior, and does
all over the place. There would be little point in the LSB if it
couldn't mandate extensions to POSIX. It is a general policy to try to
make sure that mandated extensions are exactly that -- extensions, and
not conflicts with POSIX.

Both /etc/profile.d and sh -l fit the model of legal extensions to
POSIX. But do they meet the "best practice" requirements for LSB? We
thought so at the time. I would be very happy to see lsbinstall replace
them (or at least the profile.d part).

We're back to the original problem that lsbinstall was hoped to
solve .... how do we ask the distro to place files and scripts in
distribution specific places?

Please look at
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/future-directions-annex.html
(http://tinyurl.com/2lkg9g).

If we could get every vendor to support this, then we wouldn't need
these controversial alternatives!

-- 
Nick Stoughton                          Cell: 510 388 1413
USENIX Standards Liaison                Fax:  510 548 5738




More information about the lsb-discuss mailing list