Hello,
YugabyteDB is a cloud native scalable database, comparable to CockroachDB,
which speaks both Postgres and Cassandra Protocols on wire.
Unlike CockroachDB their code and binaries are licensed under the Apache
License (1).
I would like to provide an Aport.
However their build system is unusual.
The build script forces some compiler wrapper scripts to be in specific
places and also downloads and uses build dependencies either in binary
form or source code, including the compiler itself.
I'm wondering if this way of handling dependencies is an obstacle for
the Alpine Repositories.
If this is not an obstacle, are there any preferred ways of packaging
this (i.e. leave it to the build script, or package the dependencies,
possibly with a yugabyte- prefix in the package name).
How would you package this?
I've also contacted the developers (2).
- Paul
1: https://github.com/yugabyte/yugabyte-db/blob/master/LICENSE.md
2: https://forum.yugabyte.com/t/building-system/1049
On Thu, 13 May 2021 11:29:58 +0200
Paul Zillmann <p.zillmann@h6g.de> wrote:
> Hello,
>
> YugabyteDB is a cloud native scalable database, comparable to CockroachDB,
> which speaks both Postgres and Cassandra Protocols on wire.
>
> Unlike CockroachDB their code and binaries are licensed under the Apache
> License (1).
>
> I would like to provide an Aport.
> However their build system is unusual.
>
> The build script forces some compiler wrapper scripts to be in specific
> places and also downloads and uses build dependencies either in binary
> form or source code, including the compiler itself.
>
> I'm wondering if this way of handling dependencies is an obstacle for
> the Alpine Repositories.
> If this is not an obstacle, are there any preferred ways of packaging
> this (i.e. leave it to the build script, or package the dependencies,
> possibly with a yugabyte- prefix in the package name).
>
> How would you package this?
>
> I've also contacted the developers (2).
Based on the response from upstream, I wouldn't try package it for
alpine at all. They are pretty clear that they want control the exact
versions of the dependencies themselves and hey clearly do not want
traditional distro style builds:
> but I don*t think the answer to that is to use the standard
> *configure* approach which picks up whichever versions of libraries
> that are present on the host OS.
https://forum.yugabyte.com/t/building-system/1049/2
So I'd let them do it their way. Anything else will be an uphill battle.
>
> - Paul
>
> 1: https://github.com/yugabyte/yugabyte-db/blob/master/LICENSE.md
> 2: https://forum.yugabyte.com/t/building-system/1049