Bug#570709: packaging hhvm
>On Thu, Oct 24, 2013 at 10:27 AM, Paul Tarjan <pt@fb.com> wrote:
>> It wasn¹t me, but I¹m happy to take over the conversation.
> Checked my sent-mail folder and it was you. The email I had is github
>[at] paulisageek.com .
That’s me. I checked and it came in as a notification which was filtered,
sorry.
>> Sadly, HHVM doesn¹t work on libevent 2. It was a total rewrite of the
>>API
>> and doesn¹t meet our needs.
> That's very bad and raises several issues. The main one is that who
>will support the old libevent version? Will you maintain it for
>functional and/or build problems (Debian has several architectures to
>support) including patches for security related bugs?
Yes, we will have to. It will be our fork. We have a vested interest in it
too since facebook.com runs on that too.
>> Can we either:
>> 1) distribute a libevent1.4-hhvm package with the patched .so files in
>> /var/lib/hhvm/
> Can be, but it needs precaution that other binaries don't have an
>easy way to find it and try to link with it at run time. The other way
>HHVM needs to be patched to look for libevent under that directory and
>don't get confused with the system installed version 2 of that lib.
If you point the CMAKE_LIBRARY_PATH to that directory then it should work.
>> 2) bundle the patched .so into hhvm (which I do for the one on [3])
> Hiding it under/in HHVM makes things even worse. It would make Debian
>FTP Masters very upset I think.
K, nixed.
>> 3) something else?
> Is it something like impossible to get the required functionality to
>version 2.x of libevent or it needs just too much work? Can the
>changes be generalized and make it viable to other programs as well?
>That way upstream may accept it for inclusion.
Sadly we can’t switch to 2.x without a ton of effort. The API model is
callback based instead of buffer based. Our .so is generalized enough that
others can use, but we don’t really want to maintain it for external
includes.
>> A similar thing will have to happen for libglog. That one doesn¹t need
>>any
>> patches and we work on anything 0.3.1 and higher so it might just be a
>> straightforward requirement to package.
> Version 0.3.3 is in the archive. Simple dependency will be enough. If
>you need something with it, feel free to ask me. I'm its uploader in
>Debian.
I was packaging for Debian 7 but I see it on Debian 8. Should we just
target 8?
>> As for the status of the ITP, I¹ve been trying to package it the correct
>> way, and our build environment wants to create all the temporary files
>> inline with the build instead of a subdirectory, so dpkg-buildpackage
>> doesn¹t like all the new files around. If you have a functioning
>>packaging
>> environment I would be more than happy to hand off the packaging to you.
> I've a working and up-to-date setup of course. I don't know the
>problem you refer to. Most of the packages builds inline with the
>source files I think. It's the job of '$(MAKE) clean' to delete all
>build generated files between rebuilds. It's the time to force an old
>and patched version of libevent to my setup and check the build
>process of HHVM.
Nice! Can you share that with me somehow? I’d love to see how yours and
mine differ. I don’t want to steal any credit and I’m more than happy for
you to be the packager, I just want to learn.
paul
Reply to: