[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727085: An HHVM-in-Debian State of the Union (was Re: Bug#727085: Taking over packaging in Debian.)



>	I have been working (with some help from Faidon) to bring the 2.4.1
>tarball to
>Debian standards.  The git repo (remember,
>https://urldefense.proofpoint.com/v1/url?u=http://anonscm.debian.org/gitwe
>b/?p%3Dcollab-maint/hhvm.git%3Ba%3Dsummary&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%
>0A&r=KbCGvs3NEqqV%2FJZMWI0xxA%3D%3D%0A&m=Cc%2BuMlf3PVOorM33Udvk4tQyoMy%2Bt
>%2BAWYxrtpFKq1%2BA%3D%0A&s=d572db8992a4b95f8b27e56fa11dde396e7881c8bda6de8
>a2c441adc3e61b428) reflects
>right now three major operational changes: integration of system's libzip,
>integration of system's libsqlite3 and the removal of several libraries
>that
>added useless dependencies to the package.

Yay.


>	Apart from that, the debian/copyright work is, as you may imagine, a
>three-ring
>circus.  Apart from the huge list of contributors and different licenses,
>there
>is a big showstopper that I found so far, which is that a couple of files
>are
>licensed under the (in)famous JSON.org license (Software has to be used
>for Good
>not Evil).  I'm doing my best to convince the in-house developers that
>switching
>to pecl-json-c (from Remi Collet) is the best approach as we are not
>bug-compatible anymore with the two main Linux families out there (Debian
>and
>RedHat) since the end of May 2013, but at the same time they want to stay
>close
>to PHP for good reasons.  There is an endless debate^W^W^Wmore
>information at
>PHP#63520.

This one is fun. We've chatted a bunch and the general consensus is that
the optimal outcome would be to be as compatible with php5 as possible.
This means we would like to use remi's extension (assuming all our unit
tests and the big framework tests pass). We actually don't care too much
about staying close to PHP5 at the source level since many more people are
using our packages as building from source. It also is pretty bad to have
the developers using the source be using a different library than the uses
who use the package.

So Ender, if you can get remi's extension ported to us, then we'd take it
upstream.


>	In the meantime, Facebook has released HHVM 3.0.0 with Hack support (a
>superset
>of PHP with gradual typing, collections and more stuff -
>https://urldefense.proofpoint.com/v1/url?u=http://hacklang.org/&k=ZVNjlDMF
>0FElm4dQtryO4A%3D%3D%0A&r=KbCGvs3NEqqV%2FJZMWI0xxA%3D%3D%0A&m=Cc%2BuMlf3PV
>OorM33Udvk4tQyoMy%2Bt%2BAWYxrtpFKq1%2BA%3D%0A&s=9398e7801cd780c0445cf51e09
>28831d9065d9f94a050e88fe6c5477e456bb46).
>While I'm all for packaging that version, I'm trying to stay close to
>2.4.1 as I
>already know my troubles with this version and I don't want to add more
>logs to
>the fire, so I'm not updating the upstream version yet.  Also the 3.0.0
>adds
>dependencies like some OCaml code analysis tools depending on other stuff
>that
>is not even nearly packaged, so...you know.

As far as source goes, 3.0.0 isn't much of a change. It optionally builds
the type checker if you have ocaml on your machine but happily ignores it
if you don't. So I bet if you drop it into your workflow it will 'just
work'.

Paul


Reply to: