[lsb-discuss] /etc/profile.d and LSB (test procedure missing?)
Till Kamppeter
till.kamppeter at gmail.com
Mon Apr 9 09:33:22 PDT 2007
Wichmann, Mats D wrote:
>>> I discovered that when making a CUPS package for the LSB DDK. In the
>>> maintainer scripts of the RPM (see below) I had to add the script to
>>> the end of /etc/profile (and remove this on uninstall) for
>>> non-conforming distros.
>> Any responses? This is a pretty serious issue, particularly if we are
>> telling people to use /etc/profile.d to integrate their apps with the
>> system (e.g., add to PATH etc.). -ian
>
> There's not much good to say at the moment.
>
> I'm not sure that when the /etc/profile.d wording was added that
> it was considered carefully enough. It was one of those things
> that went in on the "everybody does it this way" (aka best practice)
> principle. As far as I can tell, POSIX does not require this behavior
> of the shell, but at the time absolutely everybody used bash as
> /bin/sh so it must have seemed fine. Now that some people are
> shipping a minimalist POSIX shell as /bin/sh, and only installing
> bash as /bin/bash we've run into a problem.
>
> And no, there are no tests for this behavior.
>
> I don't think we've completely scoped out what's happening
> here, some distro feedback would be useful ...
>
Here are the reactions of Ubuntu to this problem:
First, see the bug report which I have posted and the answers of the
Ubuntu folks:
https://bugs.launchpad.net/bugs/102105
Here some citation from the IRC discussion on the #ubuntu-meeting
channel on Freenode (Weekly Ubuntu developer meeting):
-------------------------------------------------------------------------
<mdz> Mithrandir: re: bug 102105, LSB 3.1 was not a release goal
<ubotu> Malone bug 102105 in lsb "Issues of Ubuntu's LSB compliance -
Login shell startup" [High,Unconfirmed] https://launchpad.net/bugs/102105
<Mithrandir> mdz: iirc, tkamppeter milestoned it. And I think LSB is on
crack there, since they can't mandate changes to what POSIX sh should
support.
<doko> mdz: the wording is "shall" in both cases
<Keybuk> doko: what does that mean for LSB?
<tkamppeter> Mithrandir, so POSIX does not require -l and /etc/profile.d
for sh?
<Keybuk> shall implies required?
<Keybuk> tkamppeter: right
<mdz> doko: in 3.0 as well, you mean?
<mdz> we passed the 3.0 validation tests at some point
<doko> looking ...
<tkamppeter> If "shall" would not require anything, why are such terms
in the LSB?
<cjwatson>
http://www.opengroup.org/onlinepubs/009695399/utilities/sh.html <- POSIX sh
<Mithrandir> and while I think that LSB support would be nice, LSB
should not try to change behaviour of /bin/sh and similar interfaces.
<mdz> doko: what were the two cases?
<Mithrandir> and profile.d has been rejected from Debian policy multiple
times.
<mdz> that's all of the interesting high-priority milestoned bugs, at a
glance
<cjwatson> sounds like they got it into LSB by the back door
<doko> mdz: "The shell shall support an additional option -l" and "The
sh utility shall read and execute commands ..."
<Keybuk> doko: so they're both required by the LSB?
<Keybuk> (note we're nowhere near LSB compliance according to the letter
of the spec, so I don't think more non-compliance matters)
<Mithrandir> it doesn't seem like "shall" is defined in the LSB spec.
<Mithrandir> but they use shall and must.
<Keybuk> Mithrandir: those are both "required" things, Englishishwise
<tkamppeter> Mithrandir, then the LSB spec is broken.
<Keybuk> "should" is normally used in specs to mean "recommended"
<Keybuk> and "may" for optional
<doko> Keybuk:
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/def.html
so yes, it's must.
<doko> mdz: 3.0 has the same wording
<tkamppeter> Keybuk, if they are required, this bug needs to get fixed.
<Keybuk> tkamppeter: *shrug* if it isn't part of their test suite, it's
not that important
<Keybuk> I'd argue that they're trying to change POSIX-defined
interfaces there, so the LSB needs to be fixed
<tkamppeter> Keybuk, I think following the LSB wording and not only the
test suite is important, as people who make distribution-independent
packages, read the specs and do not analyse the source of the test suite.
<cjwatson> tkamppeter: I think it's a bug, but not a release-critical one
<Keybuk> tkamppeter: *shrug* nobody produces distribution-independent
packages and nobody like that cares about the LSB
<Keybuk> tkamppeter: for the first point, the LSB mandates RPM not DEB :p
<cjwatson> Keybuk: (tkamppeter does, for printing)
<mdz> tkamppeter: you may be the first to rely on this feature and
notice it...I assume you know the right people to talk to at FSG about
this issue :-)
<tkamppeter> Yes, I have already reported on the lsb-discuss mailing
list of the Linux Foundation that there are these issues with sh.
-------------------------------------------------------------------------
Till
More information about the lsb-discuss
mailing list