Subject: Re: pkg/10616: sparc/cpu.h includes non-installed kernel includes
To: None <wennmach@geo.Uni-Koeln.DE>
From: John Hawkinson <jhawk@MIT.EDU>
List: netbsd-bugs
Date: 08/02/2000 20:16:47
In message <1000731184309.ZM4500@pluto.geo.Uni-Koeln.DE>, "Dr. Lex Wennmacher" 
writes:

>I'd like to see the requirement to have the full kernel source available under
>/sys to build LKMs go away but I'm well aware of mrg's argument that this will
>be a lot of work.

It seems to be quite a small and reasonable amount of work to fix it
as the problems come up.

>I will update the arla package to check for the presence of /sys. Still, I
>consider this a (temporary) work-around as it is an absolutely sub-optimal
>solution (think bulk-builders).

Concurrance.

>> Lex, that will downgrade your PR from critical/high to non-critical/medium.
>> Can you justify the severity/priority you asserted?
>
>Actually I think that PR 10616 should also be closed. It is neither a
>port-sparc problem nor a pkg problem. jhawk, let's dupe it into
>kern/5377.

Done.

>I'd like to see the severity of this PR go to "serious",
>though (the requirement t o have the full kernel sources available to
>build a package have quite some impact).

I don't think it meets criteria:

       serious
              The  product,  component  or concept is not working
              properly or significant functionality  is  missing.
              Problems  that would otherwise be considered criti-
              cal are rated serious when a workaround is known.

At this point, I think the right approach is to propose
adding the requirement that include files in /usr/include
should work in userlevel programs with _KERNEL defined to
/usr/share/misc/style, by way of a discssion on tech-kern.

Presence of a requirement in /usr/share/misc/style does not mean
we must rototill the entire kernel to fix places where that requirement
is nonexistant, but it gives us a good standard to strive for.

Any objections to this approach?

--jhawk