musl-libc compatibility about libsolv

[mlschroe]

Oh well. Does MUSL-libc have anything similar to fopencookie/funopen?

[jmiahman]

No it wouldn't seem that way.

http://www.openwall.com/lists/musl/2014/11/11/2

I apologize as I am just reporting this and don't understand its complexities, but is this function critical it looks as though it has to do with compression could I just return 0 instead of the error message and have it go on, without breaking any major functionality?

[mlschroe]

Sure, you can do that. The basic functionality will work. The testcases use compressed data, though, so they won't succeed.

[jmiahman]

Yes the test cases were failing, so that's what I was wondering. I'm using it with libhif, hoping I can get the basic functionality of libhif working and use it as a package manager.

[Conan-Kudo]

@mlschroe Could you please write a fallback implementation that works without funopen() or fopencookie() from libc?

[Conan-Kudo]

@mlschroe This issue will be fixed if PR #112 is merged into libsolv.

[mlschroe]

Maybe, but creating a new thread is really something I don't like (I already told you that on IRC). Remember that libsolv is a library, so it shouldn't do things that the library user does not expect.

[Conan-Kudo]

@mlschroe If there is an alternate feasible approach to dealing with the lack of fopencookie(), then by all means, implement it.

The musl-libc guys do not believe that fopencookie() nor funopen() are well-defined enough to be properly implemented, and as "non-standard" functions, they don't feel compelled to implement it.

Unless you have a strong argument in favor of them implementing it, I don't see how this will get fixed without some kind of fallback implementation in libsolv.

[richfelker]

Is there a reason this functionality can't be provided by popen or pipe+fdopen and a child process or thread to do the decompression? This approach or a variant should be completely portable and likely simpler.

[Conan-Kudo]

@mlschroe Would an approach like @richfelker is suggesting be possible for you to implement as a portable fallback mechanism for libsolv instead of using the fopencookie stuff?

[mlschroe]

How's that different from using the pthread library?

[richfelker]

The difference is between emulating the fopencookie/funopen API, which isn't actually possible in general and which just happens to work for special cases that are hard to state rigorously, and using a simpler, less-powerful API directly in the way it was intended to be used. I prefer the latter because the constraints are clear and there's no risk that changes to the calling code might break the assumptions being made in the fake fopencookie.

[Conan-Kudo]

@mlschroe From my perspective, it seems like @richfelker may have a point.

While you've stated that you don't like the idea of libsolv creating threads/processes on its own, it seems that there's no way around that for this. Is it because you want to guarantee libsolv is thread-safe?

[sebcat]

Hello,

Came across this issue entry by accident. Thought I'd mention that musl added support for fopencookie(3) Dec-2017: https://git.musl-libc.org/cgit/musl/commit/src/stdio/fopencookie.c?id=061843340fbf2493bb615e20e66f60c5d1ef0455

[Conan-Kudo]

@sebcat Yeah, once that makes it to a released version of musl, this issue will be effectively resolved.

[ignatenkobrain]

Nothing to do from libsolv side.