[lsb-discuss] Clarification of general LSB requirements

[Russ Allbery]

Aaron Sowry <aeneby at gmail.com> writes:
> On Wed, 2013-07-10 at 00:54 -0700, Russ Allbery wrote:

>> Is a fake lpr that exits with a failure status acceptable on a system
>> that will *never* have a printer configured?

> No.

> An error is something like "unable to resolve MX record for the domain",
> or "no printer configured". Saying "this command isn't actually what
> it's pretending to be" is not an error - it's a foolish hack at best; at
> worst a trojan. Regardless of how well error handling has been
> implemented, no application can reasonably interpret and handle an error
> message such as that.

> If a system will absolutely, positively *never* have to send an email,
> and you feel that having a redundant sendmail command is burning a hole
> in your hard disk, then you can get rid of the sendmail completely. At
> this point it is obvious to an application why mail cannot be sent, and
> the situation can be handled appropriately.

> Of course, this would mean that the system is no longer LSB compliant,
> but that's beside the point. If this ancient practice of Linux systems
> processing email is really as horrible as some people are making it out
> to be, then simply remove sendmail from the LSB specification. However,
> just paying lip service to the spec by implementing "fake" commands like
> this is bad practice, and IMHO a violation of the LSB.

I disagree with this approach to interpreting an interface standard like
LSB.

I think a more useful approach is to follow a common practice with
standards and apply an equivalency test.  If an application cannot detect
a difference between a noncompliant system and a compliant system in a
particular configuration state, it's not really meaningful to call that
noncompliance, because the difference is within the realm of acceptable
configuration differences.

Following that principal, I would argue that it's not possible for an
application to tell the difference between a system without a printer and
a system with lpr implemented as a shell script that says there is no
printer.  The application already has to deal with the possibility that
the system has no printer, and in so doing it will cope with the system
with such an lpr command.  (As opposed to dealing with the complete
absence of an lpr command, which LSB says that it doesn't have to cope
with.)  Therefore, from the perspective of what LSB promises the
application, there is no effective difference.

Were LSB a *consumer* standard that specified what capabilities the end
user could expect their operating system to provide, that would lead to a
different analysis, since clearly such a system does not have the
capability of printing even if it were connected to a printer.  But the
point of LSB is to provide a standard application interface that portable
software can rely on.  That application interface requires the existence
of an lpr command, but does not require the existence of a working
printer.  (That would be beyond its scope, not to mention sort of silly.)
Therefore, there is no discernable difference, from the perspective of the
application that relies on an LSB platform, between a system with a fully
functional lpr command but no available printer and a system with an lpr
command that always reports an error saying there is no available printer.
Both systems are providing the set of standardized interfaces that LSB
requires.

Of course, the difference between a consumer standard and an application
interface standard can be rather murky.  If someone sold me a system with
the promise that it was LSB-compatible and I then discovered that they
never bothered to implement lpr, I would be rather annoyed (well, assuming
that I ever wanted to print something, which probably stretches
credibility).  In that particular situation, the promise does seem rather
dodgy.

But, in the example that you raise, this is an optional configuration.
Indeed, at least at present and in all previous releases of Debian, one
has to go out of one's way to get the lsb-invalid-mta package installed,
since a fully functional mail transport agent providing the sendmail
command is part of a standard Debian installation.  You have to go out of
your way to remove it.  So the scenario I describe above doesn't really
apply, and the problem reduces to whether the installation of the Debian
lsb-core package should guarantee that a fully functional sendmail program
is present on the system (but possibly not configured), as opposed to
delivering one by default but allowing the local systems administrator to
choose to replace it with a error-producing stub without removing the
lsb-core package.

(It's probably also worth noting that Debian does not claim LSB compliance
and the description of that Debian package states, rather prominently:
"The intent of this package is to provide a best current practice way of
installing and running LSB packages on Debian GNU/Linux.  Its presence
does not imply that Debian fully complies with the Linux Standard Base,
and should not be construed as a statement that Debian is LSB-compliant."
So, really, it's kind of hard to see what's notably egregious about this.)

Anyway, I think it's worth bearing in mind that the point of the LSB is
about guaranteeing a standard set of interfaces to binary executables so
that they can be run portably across a variety of Linux systems.  The
answer to a compliance question always depends to some extent on why
you're asking the question and what you're trying to accomplish.  My point
is that asking for LSB compliance to guarantee that an application is able
to send email is actually asking for quite a lot, and, in practice, is
more than the LSB is going to be able to provide, for a variety of
reasons.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>