[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