epoll, LSB (was: Re: Problem roundup)

[Dan Kegel]

Mike Hearn:
> 1) The RH9 RPMs are apparently being compiled with epoll support linked
>     in. This is causing user pain. We should really be using dlsym here,
>     why are we not again?

Alexandre Julliard:
> glibc is not backwards compatible, the RH9 RPMs should be built
> against the RH9 glibc. There is nothing special about epoll, you can
> have the same issue with any glibc symbol, and we can't start
> dynamically loading them all.

Mike Hearn:
 > We don't have to be over-general about it, just dynamically loading the
 > ones that cause problems would be fine (or using syscalls directly). The
 > vast majority of the symbols are always there and so it doesn't make sense
 > to use dlsym.

Alexandre Julliard:
 > I think it's much better to ask packagers to build their packages
 > correctly, it will cause much less trouble in the long run.

Or better yet, ask people to download the right package.
I just downloaded
http://prdownloads.sourceforge.net/wine/wine-20041019-1rh9winehq.i686.rpm
and it worked fine on RH9.

I wonder, though: the fact that somebody downloaded the wrong
package means there are probably too many different versions
at sourceforge to download.  I count 24 packages!  (OK, a few of
them are srpms.)  Shoot, can't we package Wine as an LSB package?
I suspect Wine depends on nothing that isn't in the LSB.
That'd make life a lot easier for the users... at least for
those whose distros come with LSB support installed by default.
- Dan
-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html