Hi Christop,
Thanks for giving us a heads up regarding the key life time.
I've read through:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761817
(which is probably related to this mail?)
and have some remarks:
- V8 does not provide a stable API across versions, so you need
exactly the version that we use (or that release series).
- we apply some patches to V8, mostly build system related, however
some of them patch away some "Resources empty? Geronimo!!!!" code which
is not nice to have in a database - that will auto-terminate without any
feedback then.
- Rocksdb - same here. While we send patches of our changes upstream,
they may only become available in later versions which may not be api
compatible - so if I strongly sugest to use the version shipped with
arangodb.
- Boost - you most probably need the version we use, it should be ok
to use a system provided version
- snappy - whatever is newer probably is better. needs to work with
rocksdb.
- s2 (not yet in your list) - probably needs to be exactly the shipped
version with ArangoDB 3.4
- curl - you can probably use newer versions.
- velocypack - our binary json representation
https://github.com/arangodb/velocypack/ - to be honest we didn't yet
work with tags here so you could identify whats released with which
arangodb - we need to fix this.
- fuerte - our binary transport c++ library - issues see velocypack.
- iresearch - needs to be a matching version, however upstream is also
maintained by us.
- ICU - we use the one bundled with V8 - don't know whether there is a
good way to include a system one
Up to arangodb we used cpack to generate debian packages, accompanying
scripts can be found in Installation/debian; This is probably why you
don't find a debian/ directory.
With ArangoDB 3.4 we migrated to statically linked binaries with libmusl
- compile once, bundle into tar/rpm/deb; The currently used debian
scripts can be found here:
https://github.com/arangodb/oskar/tree/master/debian/3.4
Since we need to be able to ship bugfix versions, we do this with the
third version digit incrementing. So Arangodb 3.3.20 can be treated as a
bugfix version of 3.3.19.
The current arangodb cmake build is intended to bundle and bring all
required 3rd party libraries, I don't know how well it can be configured
to prefer system installed ones.
If you have more questions regarding compiling arangodb don't hesitate
to ping me via slack or github issues.
Cheers,
Willi
ps: there are only rspec / ruby tests remaining which probably shouldn't
be represented in the final package, the ruby tag of the initial wnpp
can probably be removed.
---------- Forwarded message ---------
From: *Christoph Biedl* <debian.a...@manchmal.in-ulm.de
<mailto:debian.a...@manchmal.in-ulm.de>>
Date: Mi., 12. Dez. 2018 um 01:11 Uhr
Subject: [info] Upcoming Debian repository signing key expiration
To: Frank Celler <i...@arangodb.com <mailto:i...@arangodb.com>>
Hello,
thanks for providing arangodb packages for Debian, and especially for
providing a GPG signature for these. However, there is a problem coming:
The key as provided at
https://download.arangodb.com/arangodb34/DEBIAN/Release.key
has an expiration date less than six months into the future:
| $ gpg --list-key EA93F5E56E751E9B
+ pub rsa4096 2015-06-02 [SC] [expires: 2019-06-01]
| CD8CB0F1E0AD5B52E93F41E7EA93F5E56E751E9B
| uid [ unknown] Frank Celler (ArangoDB Debian Repository)
<i...@arangodb.com <mailto:i...@arangodb.com>>
+ sub rsa4096 2015-06-02 [E] [expires: 2019-06-01]
From my experience, deploying a new signing key is a lengthy process,
so I'm asking you to start it as soon as possible. Unfortunatley, the
risk users out there will not install it in time is already quite high.
Regards,
Christoph
