[OpenIndiana-discuss] e2fsprogs header file bug

[James Carlson]

Andrey N. Oktyabrski wrote:
> On 28.10.11 16:29, James Carlson wrote:
>>> In which bug tracker I must create a bug report for this issue?
>>>
>>> The problem is that on OI-151 EXT2_IOC_GETFLAGS is defined as
>>>      _IOR('f', 1, long)
>>>   where _IOR is defined in drm/drm.h which is not included.
>>>   To me this looks like a bug in OpenIndiana.
>>
>> At a guess, I suspect that what's going on here is that you have a
>> /usr/include/ext2/fs.h that's delivered by libparted, and this other
>> software is "assuming" that if this file is present, then all things in
>> it must work and it must correspond to a kernel feature.
> Where you see the "fs.h"? ext2fs/ext2fs.h

I was diving in libparted because I didn't have ext2fs/ext2fs.h on my
OpenIndiana system.  :-/

>> I think that's a bit of a brash assumption on the part of the author of
>> that libarchive software.  Just because you troll through /usr/include
>> and find a file there does not automatically mean it'll do what you
>> think it does -- basically, any package can add a file to that directory
>> for any reason, not just bona fide parts of the OS.
> Yes, I agree, but this is a separate bug :-) And this bug is not
> IO-related.

I still disagree that depending purely on the existence of a header file
is the right way to build portable software -- it's likely necessary,
but almost certainly not sufficient.  Good luck to the users of that
software, I guess.

>> One thing you could do would be to find out what installed that file,
>> and then go ask the author of that package whether he thinks he should
>> be delivering the file:
>>
>>     pkg search -lp /usr/include/ext2/fs.h
> $ pkg search -lp /usr/include/ext2fs/ext2fs.h
> PACKAGE                                           PUBLISHER
> pkg:/system/file-system/e2fsprogs at 1.41.14-0.151.1

That doesn't come with the system.  It's part of OI-SFE.

Looking over the software, it doesn't look to me like anyone should
assume that if the header files are present, then the kernel bits are
present as well.  These programs are for "compatibility" -- specifically
on systems that lack those Linux-specific file systems.

>> My guess, though, is that he's really not at fault here, and that the
>> fault really lies with the software that is making assumptions about
>> what those files represent.  Writing portable software is harder than
>> that.  Reading through that problem report, though, makes it sound like
>> those other developers aren't going to agree with me.  :-/
> I think, if any header file uses some macro, it must include header file
> with definition for this macro. Am I wrong?

To that last question, I'd say "yes."

I can see no need for any requirement that all of the macros defined in
a header file must be usable in all contexts.  There are cases where the
macros defined are usable only in certain contexts -- such as when
building a kernel module or when compiling for debug or with certain
optional features.

Yes, I do think that, as a design point, it's a good thing for header
files shipped with the system to be stand-alone, meaning that they can
be compiled successfully without needing prior includes.

But, aside from that, I don't believe it's a requirement that anything
inside is usable by anyone, unless it's actually _documented_ to be
useful.  In this case, I can see no documentation related to e2fsprogs
that suggests that including this header file will somehow get you
EXT2FS-related kernel ioctl support.

You might have an argument that e2fsprogs shouldn't include this header
file.  Most projects (for what it's worth) just toss in the kitchen sink
-- anything that's built is shipped, even if it's not normally useful
for anyone outside of the project.

Perhaps Ken Mays might have something to say about it.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>