On Mon, Dec 15, 2025 at 04:01:04PM +0000, James Le Cuirot wrote: > 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.
It's been pointed out to me that this was already proposed in GLEP 70. The initial proposal suggested baking this into PMS with an EAPI bump, but others commented that there was no need. I myself have learned that it is better to avoid that if you can. Beyond that, there was some discussion over exactly how it should be done, including the pros and cons of reading the values from /etc/os-release. That was my original idea, but I felt it was needlessly complicated. Having the variables defined in the base profile was seen as a potential downside. Downstreams who don't want to change these values may not want to use the base profile. That seems unlikely, but we can avoid that by defining the defaults in the eclass rather than the base profile as I have done. Downstreams who do want to change these values may not want to create their own profiles. That also seems unlikely, but even still, they could alternatively set the variables in make.conf or the environment. Most importantly, what I have proposed doesn't change anything for existing Gentoo users.
