Kfir Lavi wrote:
> Does configure tests check the running kernel for compiled in interfaces?
> If yes, lets say I have very lean kernel on the target, how I can compile
> against the target kernel?

This is a non-issue for most packages because the kernel interface
can be considered stable. Do you have a problem with some package?


//Peter

Enrico Weigelt wrote:
> > > say I have very lean kernel on the target, how I can compile
> > > against the target kernel?
> >
> > This is a non-issue for most packages because the kernel interface
> > can be considered stable.
>
> No, they can't, especially in embedded world.

Obviously there is a limit to every definition of stable. But it is
my impression that Linux does not change API at a whim.


> The biggest problem is certain ill-designed packages which try to
> guess something from the *running* system. This can only be solved
> in the source.

Sure, and this is a problem with individual packages. Not so much
with the kernel. The packages can be fixed.


> > Do you have a problem with some package?
>
> Just from the tip of my head, in recent years: network utils,
> drbd, etc, ...

Because the recommended API to use was changed, or?


//Peter

Enrico Weigelt wrote:
> Little example, where I'm working on right now: coreutils and gnulib.
> Imagine, these jerks not just collected hundreds of (sometimes really
> broken) tests and workarounds instead of fixing the source - they
> also collected them in another "package" called gnulib, which gets
> fetched via git (from the current head instead of some release tag!)
> and _copied_ into the coreutils source tree by some obscure
> "bootstrap" script. Wow, self-modifying code.

I agree that this is a deficiency, and that there should instead be
an explicit dependency on what is effectively an external package.

But usually this is easy to fix in an ebuild.


//Peter