[lsb-discuss] Clarification of general LSB requirements

Aaron Sowry aeneby at gmail.com
Wed Jul 10 11:49:05 UTC 2013


On Wed, 2013-07-10 at 02:10 -0700, Russ Allbery wrote:
> 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.

In the case of Debian, the main issue is that lsb-invalid-mta is an
awful solution to an almost non-existent (as you mentioned above)
problem.

The fallout from this is that things which expect sendmail to behave
sensibly suddenly break. For example, those few Debian administrators
who have installed lsb-invalid-mta will no longer be notified by cron
when their nightly backups fail, or when their logs aren't rotated
because /var is full. Ubuntu admins will suffer from this problem
straight out of the box.

This type of thing is distribution-specific and should really be
discussed in more appropriate forums, however it does illustrate that
applications have some expectation of functionality regardless of how
you choose to interpret the spec.

> 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.

Requiring an application that "is able" to send mail is not the same
thing as requiring an application that "is guaranteed to" send mail, and
I don't think it's asking for a lot.

You're correct that an application cannot distinguish between an actual
"no printer configured" error and a faked one, and according to some
interpretations of the LSB the faked behaviour may even be considered
compliant. My point is that these interpretations are misleading and
dangerous, not least of all for the poor system administrator who hangs
himself in the server hall because he can't figure out why his printer
isn't working, despite being perfectly configured. If such behaviour
*is* considered strictly LSB compliant, then the problem is instead that
the distribution is shipping a completely broken lpr. Allowing such
interpretations of the LSB encourages distributions to ship broken
packages, and end up with problems like the one discussed above.

> I suspect you're not going to like this answer from me any more than
> you liked it from Jeff.  :)

Nah, I don't like it, but if there's a consensus then I'm willing to
accept it. All it means is that the LSB becomes irrelevant for us, and
we'll have to specify system requirements ourselves instead.
Distribution-specific hacks such as lsb-invalid-mta will have to be
worked around. But, such is life. You don't always get everything you
want. :)



More information about the lsb-discuss mailing list