[lsb-discuss] RFC: interfaces - candidates for LSB 3.2 or later

Wichmann, Mats D mats.d.wichmann at intel.com
Tue May 29 11:20:06 PDT 2007


> a.) add getdomainname to LSB and commercial apps can certify
> b.) create a work around function which implements getdomainname() and
> is distributed with the LSB SDK to allow application
> developers to link an additional object or compile in the code. 
> Therefore allowing commercial apps to certify 
> c.) tell commercial developers that the LSB is not for them. 
> 
> IMHO a.) or b.) are preferable solutions. It appears you feel very
> strongly about c.) being the best approach.

We have a relatively short window before wrapping up 3.2,
but I hope we can explore (b) a little bit to see if it
would work. I don't think anybody is advocating (c), but
it has to be noted this is an odd case:  the object in 
question is a closed blob, nobody knows what it does.

For example, I know of a piece of code that pokes around
to see if there is an /etc/resolv.conf; if there is, it
assumes BIND/DNS service is available.  Then it checks
to see if getdomainname returns something useful; if so,
it assumes NIS service is available.  If no luck so far,
it looks for /etc/hosts to see if resolution can be done
that way.  None of those three checks would be LSB conforming,
since none of those items are specified today. On the other
hand, they're all superfluous: glibc's name resolution 
routines are designed so that they work sensibly whatever 
set of services are configured behind the scenes; there's
not supposed to be any reason to go figure out what the
particular services are.

Despite that little aside, if the code we've been talking
about does something similar - it's one of several checks,
and suitable fallbacks exists if the answers don't look
sane, then getdomainname shouldn't be a big issue.  On the 
other hand, if specific assumptions are made based on the
existence of a getdomainname interface, then we're in worse 
shape,  because as Nick notes we don't really know how to 
specify what it might return without potentially having to 
drag in other things. How would I write a meaningful test for
an interface whose only legal response is the string "(none)",
but where we might expect people to make assumptions based
on other, unspecified, values?

It's the black hole aspect that makes this particular case
a concern.




More information about the lsb-discuss mailing list