Bug#727085: Taking over packaging in Debian.
Hi Ender, all,
On Fri, Feb 28, 2014 at 8:16 PM, David Martínez Moreno <ender@debian.org> wrote:
> Hello all. My name is Ender, I have been a Debian developer for quite some
> time and I work for Facebook, so I decided to do proper packaging of hhvm in
> Alioth, as having this done properly is a goal for the team in the first part of
> the year.
I was wondering if one of us is working for Facebook or not. I
suspected yes, as we are everywhere and I'm right.
> I've read the entire thread to become familiar with everything discussed so
> far, and I will be incorporating some of the suggestions discussed here as well
> as some decisions that we made as a team.
Can you share those decisions?
> All the development for now is happening on collab-maint/hhvm [1], as the
> current Github repo structure does not fit really well the layout of
> git-buidpackage.
Quickly peeking into your packaging I do wonder if you read the
entire bug thread.
For example I've discussed architecture support with Paul Tarjan
(message 50)[1]:
-- cut --
From: Paul Tarjan <pt@fb.com>
Date: Wed, 6 Nov 2013 16:51:46 +0000
>Last but not least that wiki forces HHVM to be amd64
>only. Any reason to do that? Any known problem to run HHVM on
>kfreebsd-*, mips{,el}, sparc or any other archs that Debian supports?
Absolutely. HHVM is a Just-In-Time compiler which emits assembly code into
memory then executes it. We currently only emit 64bit x86. We are looking
at other backends, but they require a lot of effort to implement and
optimize.
-- cut --
Still, you put the binary package architecture any, instead of only
amd64. Does Facebook supports for example mips now?
In that mail you can also read that I've identified most of the build
dependencies. May I ask why you don't use any of that?
Can it be that you use the embedded sources, those as Paul acknowledged:
-- cut --
> I've just realized that HHVM
>embeds other codes under hphp/third_party/ , even folly which is an
>other FB FOSS software and should be packaged separately.
Folly is pulled in with a git submodule, but yes, the others are copied in.
-- cut --
Those should be ironed out and use the packaged versions expect Folly
as an other Facebook employee wrote the following.
-- cut --
From: Jordan DeLong <delong.j@fb.com>
Date: Sat, 4 Jan 2014 19:44:26 -0800
On Sat, Jan 04, 2014 at 11:53:25PM +0100, László Böszörményi (GCS) wrote:
> Question is, does Folly maintain ABI compatibility? If it changes
> from time-to-time, how often?
Yeah, it doesn't attempt to maintain ABI backward compatability, and
we haven't done much about tracking when we break source-level
backward compatability either. (As Sara said, we don't version it
currently... unless you count the submodule in hhvm ;)
There are changes probably a few times a week, although I'd suspect
few of the changes that aren't to new components (usually in
folly/experimental) actually break source backward compat.
-- cut --
As such, we have to trust that Folly is as up to date as possible in
HHVM and it will be supported for Debian/Ubuntu stable releases (at
least five years if I count in Ubuntu LTS releases).
I've asked Paul about other embedded libraries, but didn't get an answer.
-- cut --
But problems arise with other libs as well. For example libafdt is
version 0.1.0 (hardly a version number to call it final and stable),
which was last released in 2009 (yes, almost five years ago!). I've a
package ready, but it doesn't build a shared library, just a static
one and it has only one header file. I may upload it if you really
want, but I don't see a reason for that. I've a package of libmbfl as
well, version 1.3.2 , which is 'just' two years old. The version
included in HHVM is 1.0.2 (according to
hphp/third_party/libmbfl/mbfl.rc) and I don't want to think about how
old is it. Don't forget the Folly state (no ABI and neither source
stability), the history of old libevent version usage, makes me wonder
how HHVM works in the long run, how supportable is it. There's 'good'
news of course, like Sqlite3 is version 3.7.15.2 which is 'just' one
year old. While its homepage shows that the last release is 3.8.2 and
upgrading from versions before 3.8.1 is strongly recommended due to
the number of bugs fixed. OK, the only one database corruption bug
fixed (in 3.7.16.2) since the included 3.7.15.2 is a rare one.
Still, forgive me Paul for asking but why do you include and use well
rotten, quite old versions of libraries? Several of them are packaged
in modern distributions and kept fresh and clean.
-- cut --
May you answer this part? For example Sqlite3 became more than a year
old in HHVM now. Upstream version is 3.8.3.1 ATM. Paul didn't answer
this for a while now. :-(
I accept the fact that Facebook wants this packaged for Debian in the
first half of 2014 and you take over the packaging without asking me
(probably ignoring Ondřej and Faidon as I didn't see them as Cc in
your mail), but as you read in the mails you mentioned and I already
put enough hours into this, at least set the architecture right to
amd64 only.
Last, but not least did you read the message from Ondřej Surý that
HHVM should be packaged under pkg-php-maint? Any reason to just use
collab-maint?
An other project from Facebook, Flint also have some issues
unanswered[2] from a Debian Developer. May you route those to someone
with proper knowledge?
Kind regards,
Laszlo/GCS
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=50;bug=727085
[2] https://github.com/facebook/flint/issues
Reply to: