flatcar
Discussion: Updating and Maintaining Flatcar ebuild Files (e.g., etcdctl-3.5.0.ebuild)
Context
We have several ebuild files used for building Flatcar components, such as etcdctl-3.5.0.ebuild. This particular file has caused issues related to how dependencies are included, and there are concerns that its current style may not adhere to modern or recommended practices for ebuild files.
Points for Discussion
- What are the known problems with the current ebuild files (e.g., etcdctl-3.5.0.ebuild)?
- What is the recommended way to include dependencies in ebuild files today? Are there upstream guidelines we should be following?
- Should we establish a process or checklist for updating our ebuild files, and if so, what should be included?
- Which ebuild files in Flatcar are most in need of review and update?
- What are the risks of updating these files, and how can we best test and validate changes?
Call to Action
Please share your experiences, insights, or links to documentation that can help us improve the way we maintain and update our ebuild files in Flatcar. Let's agree on best practices and define actionable next steps for updating problematic ebuilds.
If you're referring to EGO_SUM, which I said was deprecated, then its downsides are not an issue for Flatcar, as we only include packages that Flatcar actually needs. The problem would be if support for it were dropped from the eclass. This actually seems quite likely, as no ebuilds in Gentoo's main repo actually use it. It's possibly being kept around for overlays, but that could change anytime.
Short of implementing an all-singing all-dancing src_fetch that can work with Go to cache modules for later use with proper verification (bike sheds, ahoy!), the recommended approach is to create a tarball of the vendored modules and host those somewhere, assuming upstream doesn't do that for you. They almost never do.
Having said all that, Gentoo has its own etcd package that is far more up to date than ours. Someone should check why we forked the package in the first place. Perhaps Gentoo just didn't have it back then. The server can be disabled with a USE flag, and we can INSTALL_MASK anything else we don't need. I don't think there are any compatibility issues, as etcdctl can work with older server versions IIRC.
Someone should check why we forked the package in the first place. Perhaps Gentoo just didn't have it back then.
Not sure if that was "forked". It is hard to know, because most work was done long time ago.
In 2013 CoreOS Container Linux added its own etcd ebuild as well as etcdctl ebuild. In 2016 they added etcd-wrapper to replace etcd, and in 2018 dropped etcd. Only etcd-wrapper and etcdctl remained through the CoreOS-EOL-Flatcar era. etcdctl was updated only when needed, like the last update in 2021.
Until 2016 Gentoo seems to have both dev-db/etcd and dev-db/etcdctl. But in 2016 etcdctl was merged into etcd.
To me it seems to be just one of the corner cases of two different lines of developments existed in parallel.
The server can be disabled with a USE flag, and we can INSTALL_MASK anything else we don't need. I don't think there are any compatibility issues, as etcdctl can work with older server versions IIRC.
Yes, for etcdctl case, let's try to simply use Gentoo ebuilds. That would be much easier to have an unmaintained ebuild.
