Package Base Details: clickhouse-bin

Git Clone URL: (read-only, click to copy)
Submitter: thebits
Maintainer: thebits
Last Packager: thebits
Votes: 8
Popularity: 0.51
First Submitted: 2020-05-08 12:53 (UTC)
Last Updated: 2024-06-07 05:15 (UTC)

Latest Comments

Fijxu commented on 2024-03-03 02:37 (UTC)

Thanks for maintaining this pacakge.

ottbot commented on 2022-10-13 19:08 (UTC) (edited on 2022-10-13 19:11 (UTC) by ottbot)

It makes sense only because it is how Clickhouse builds, documents, and distributes their product. I tend to choose AUR packages that (1) simply take the shortest path from upstream documentation, (2) follow naming conventions on source vs binary packages, (3) don't make naive assumptions, and (4) aren't hostile to users

It's entirely your prerogative if want to offer a build that reflects your opinions, experience, and goals.

I'm not interested in a more expansive discussion, this stuff is pretty well covered and I think @thebits has done a good job here.

Felixoid commented on 2022-10-13 09:30 (UTC)

Actually, it doesn't make sense to have split packages. client and server contains only symlinks.

clickhouse package has been existing for five years. The clickhouse-server and clickhouse-client themselves are pretty useless w/o a single static binary that is in clickhouse-common-static package.

The question is what to use, tgz or deb as well is opinionated, they are 100% the same

Building the static binary on a usual laptop/host is around 1-1.5 hours, just in case

ottbot commented on 2022-10-12 23:30 (UTC)

For what it's worth, this base package is what I expected to find after looking here:

There shouldn't be two binary packages on AUR. If no one wants to maintain a source-based PKGBUILD (for now), I think the other package should be removed in favor of this one. It doesn't make much sense to offer both, and the tgz one seems more conventional.

It would probably be more practical to then change the non "-bin" packages a to be similar to how this one is grouped. You can still build from big static lib from source without getting all of it's dependencies (that are pulled in the upstream cmake project's git submodules) from Arch, right?

Felixoid commented on 2022-08-19 16:36 (UTC)

If you'd like to help with updates, I'd be happy to add you as a co-maintainer. Mentioned packages have one more advantage in multiple supported architectures.

One updated package will play better than a few maintained by different people. What do you think?

thebits commented on 2022-08-19 14:49 (UTC)

Hi @Felixoid! Thank you for you attention to my package.

There is no special reason. This is my first package. I studied and experimentied with it.

Users feel free to choose a package with deb or with tgz as a source. I update the package more often.

Felixoid commented on 2022-08-19 13:37 (UTC)

@x1unix as far as clickhouse heavily depends on custom tweaked libraries, the only convenient way to get it in the OS is using official packages. I doubt one will try to maintain a custom build job.

Felixoid commented on 2022-08-19 13:34 (UTC) (edited on 2022-08-19 13:38 (UTC) by Felixoid)

What is the reason behind reinventing the wheel, actually?

As a maintainer of the upstream packages, I can assure you the tgz is 100% the same content as the deb, which is used in the clickhouse and clickhouse-lts packages.

What problem did you try to solve with this package base?

x1unix commented on 2021-07-20 14:38 (UTC)

I hope that this package will appear in the main repo soon.