I am proposing the introduction of a branding eclass to act as a single source
of truth for places where we might include strings like "Gentoo" or our Bugzilla
URL in the build of a package. Apart from avoid duplication and making it easier
to change these in future, it also allows users and downstream distributions to
set their own values.
To be clear, yes this is for Flatcar, but this is absolutely not about hiding
our Gentoo parentage. In fact, we're very proud of it. See my FOSDEM talk. :)
It's really because of things like ls --help.
Report Gentoo bugs to: https://bugs.gentoo.org/
Although Flatcar is built from Gentoo, the end result is nothing like a regular
Gentoo system, so we think it would be very impolite for Flatcar users to report
bugs directly to Gentoo. I don't think you want that either.
I'm very open to improvements. Are the variable names unique enough? I couldn't
find any clashing instances in Gentoo's ebuilds.
I know EAPI 9 is almost but not quite here yet, but this only sets variables, so
I thought I'd add that support early.
I've tried to keep OS_PRETTY_NAME flexible. It can include the version, but it
doesn't have to. `${OS_NAME} ${OS_VERSION}` is a reasonable fallback, but it
doesn't match what we have in os-release right now, hence not using that as the
default.
I have included the changes to the most obvious packages, but there are plenty
more packages it could be applied to.
I haven't included the associated changes to baselayout itself, but obviously it
would just make use of these variables. I could have it bail out if they're
unset or just repeat the defaults there. Flatcar actually has its own baselayout
and sets os-release separately anyway, so we don't need to change Gentoo's
baselayout, but I feel like it should be consistent with the eclass.
