Bug#570709: packaging hhvm
Hi Paul,
I'd other things, but back on track.
On Thu, Oct 24, 2013 at 11:23 PM, Paul Tarjan <pt@fb.com> wrote:
>>On Thu, Oct 24, 2013 at 10:27 AM, Paul Tarjan <pt@fb.com> wrote:
>> 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 Facebook do the fork then? Meanwhile I've packaged the latest 1.x
release with the HHVM patch applied[1]. I need to check if v1.x and
v2.y can live together though.
Does FB know that other event libraries are exist as well[2][3]? The
latter states that it's "a full-featured and high-performance event
loop that is loosely modelled after libevent, but without its
limitations and bugs".
> 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.
But it would be better on the long run. If you stick with version
1.x, you need to support an obsoleted version. With the 2.x switch,
you'd get development (possibly performance increase with time) for
free. Anyway, some weeks ago I've read that FB has its own event
library, coded in plain C. Even faster a bit than libevent in certain
workloads. Can't find it now. :( But maybe that would be a better
dependency for HHVM.
> I was packaging for Debian 7 but I see it on Debian 8. Should we just
> target 8?
Uploads in Debian can go to two 'branches'. The first is Sid, the
everytime unstable and to experimental. All development happens in
unstable. Experimental is used for playing and testing with packages
that may break the system hard. Packages goes to testing after a
specific time is passed without serious bug reported against it
(default to ten days). To stable versions (currently version 7.1,
codenamed Wheezy) only the security team can upload.
>> 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.
The internet is full with howtos on this topic. Keywords are
debootstrap and/or pbuilder. I can write you specific URLs with
detailed steps if needed.
Last time I was very close to compile HHVM, but it still failed with
some 'this library needs a specific patch' error message as far as I
can remember.
Regards,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/libevent_1.4.14b-stable-1.dsc
[2] http://software.schmorp.de/pkg/libeio.html
[3] http://software.schmorp.de/pkg/libev.html
Reply to: