Closed repeatedly closed 4 years ago
Another good reason to drop Omnibus support is that it is hard to use in enterprise settings that require internal mirroring of all 3rd party build dependencies. Since Omnibus pulls all the dependencies from different external sources and there is no way to guarantee that those sources will always be available (such as seen in this recent incident: https://github.com/treasure-data/omnibus-td-agent/issues/216), the build can be unstable.
Hi, (I'm a one of a Debian Maintainer so it may have some bias in my opinion)
Surely Omnibus based packaging has some merit for many platforms(we can install td-agent as a package and it doesn't affect system's ruby and so on), but as repeatedly described above, It seems that there are some drawbacks.
If there is not strong reason to provide td-agent in one single binary package (td-agent.deb or .rpm), it may be better to split it into multiple packages in point view of package maintainer for simplicity.
For example, split current td-agent into two packages:
In above packages, it assume that it is able to execute debuild or rpmbuild directly (it means that debian/* or spec file is not separated) without Omnibus, so things become simple (it can be able to get feedback from other deb/rpm maintainer) and td-ruby will be able to use system's openssl, thus, it means that it makes easy to follow security updates.
If build process is simplified as above, it makes easy to migrate into docker based build process. After that, it makes easy to integrate existing CI service such as Travis CI, GitHub Actions and so on. How do you think about split package and make them docker ready?
https://github.com/treasure-data/omnibus-td-agent/issues/219#issuecomment-549638661 doesn't care about Windows or macOS cases, I'll plan to update description.
On Windows or macOS replacing omnibus is not so good idea because it seems that it is similar to reinventing the wheel in current status and need to tackle for it
Instead, improving to use CI service(Travis?) may be better for light-weight mechanism for td-agent.(One concern is execution timeout on such CI service) How do you think about this approach?
On Windows or macOS replacing omnibus is not so good idea because it seems that it is similar to reinventing the wheel in current status and need to tackle for it
I'm now considering other solutions.
On macOS, Homebrew, Fink and MacPorts are well known. Probably Homebrew is the best solution recent days. On Windows, Chocolatey seems pretty.
BTW recent Windows has a package management system "PackageManagement" (a.k.a "OneGet") by default which abstracts several PackageManagementProviders like NuGet or Chocolatey.
Homebrew seems good. Like mikutter does. https://github.com/Homebrew/homebrew-core/blob/371a81a6b53aabe8ab09206a25592871a06637ee/Formula/mikutter.rb
I'm sorry for long silence. As @repeatedly mentioned in https://github.com/treasure-data/omnibus-td-agent/issues/209#issuecomment-599378907, we are developing a new lightweight build sytem for td-agent:
Now it's ready for testing! Please feel free to test it & report issues.
Current status of this build system:
Thanks! I will try td-agent 4 build with td-agent-builder :)
Additional comments:
The path element "embedded" is removed in new packages
Awesome :)
Basic work of td-agent-builder is done.
We introduced omnibus to reduce maintenance cost for many platforms several years ago. I'm not an expert for deb/rpm/dmg/msi packaging and the maintainer was only me, so omnibus is good project before.
The drawbacks are:
We have some experience and we now have container/CI/CD tools for packaging. Time to consider more light-weight and better packaging mechanism for td-agent.