~alpine/devel

1

Packaging YugabyteDB

Paul Zillmann <p.zillmann@h6g.de>
Details
Message ID
<683fbf70-1ee4-4da8-e76f-45a897f3b8f9@h6g.de>
DKIM signature
missing
Download raw message
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
Details
Message ID
<20210513124715.1c874b97@ncopa-desktop.lan>
In-Reply-To
<683fbf70-1ee4-4da8-e76f-45a897f3b8f9@h6g.de> (view parent)
DKIM signature
missing
Download raw message
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
Reply to thread Export thread (mbox)