Hi all,
Currently, TsFile C++ users generally need to build from source and prepare the required dependencies themselves. To simplify installation, I propose gradually supporting Homebrew, APT, Yum/DNF, and other mainstream package managers for installing libtsfile, development headers, and command-line tools. Apache source releases approved by the community will remain the basis for building these packages. I suggest proceeding in the following stages: 1. Standardize installation artifacts Provide consistent installation rules for libtsfile, public headers, CMake Package Config files, pkg-config metadata, and CLI tools. We should also define the library version and SONAME policy. 2. Support local package generation Use CPack to generate .tar.gz, .deb, and .rpm packages. The initial packages can be divided into runtime, development, and CLI components for CI validation and early user testing. 3. Improve third-party dependency management This work will be based on the ongoing third-party dependency discussion: https://lists.apache.org/thread/1ssk1rot302cx88pkt3rvzxjr19kpppr Native Debian, Fedora, and Homebrew packages should use system dependencies, while portable binary packages may use pinned bundled dependencies. The final implementation will follow the outcome of the community discussion and vote. 4. Build package CI CI should validate package generation, installation, upgrade, and uninstallation. It should also use an independent CMake example project to verify the installed libtsfile library and headers. 5. Publish packages incrementally We can first provide community testing channels such as a Homebrew tap and test repositories for APT and Yum/DNF. Once the process is stable, we can gradually apply for inclusion in Homebrew Core, Debian/Ubuntu, Fedora, and EPEL. Official repositories will require platform-specific packaging files, such as a Homebrew Formula, Debian packaging files, and an RPM spec, rather than directly using the CPack-generated packages. I would especially appreciate community feedback on: - Whether the proposed package and component structure is appropriate. - Which operating systems and package channels should be prioritized. If the community agrees with this direction, I will start with the standard installation rules and local package generation, and submit the implementation incrementally through separate pull requests. Comments and suggestions are welcome. Thanks, Colin
