On Thu, 15 Dec 2016 21:49:15 +0000 "Robin H. Johnson" <robb...@gentoo.org> wrote:
> I do really agree that how we offer branding should be covered in a > GLEP, and be very easy for downstream offshoots of Gentoo to follow. > This would prevent future concerns like the Ubuntu branding / modified > VM spats. > > [snip awilfox's superb proposal; I agree with all of the reasons and > outcomes, but think a little bit more structure & flexibility are > needed]. > > On Mon, Dec 05, 2016 at 08:46:53AM +0100, Michał Górny wrote: > > Strictly speaking, it could use $EPREFIX/etc/os-release which has all > > the info you need, is installed by baselayout and doesn't require > > special wrappers to print it. > ... > > The other alternative is to provide an eclass that reads data from > > $EPREFIX/os-release and supplies it to the packages that need it. > > I've been wondered about this, since reading awilfox's PR, and I have > some tweaks & extensions to offer to their proposal. This resolves all > of the drawbacks noted by mgorny, supports branding information via > profiles (or other means). Thanks. I like it. A few comments though. > 0. This proposal is centered around using os-release, as a > cross-distribution model. > 1. ebuilds: Add eclass to export all variables from /etc/os-release with > a prefix: > OS_RELEASE_ID > OS_RELEASE_NAME > OS_RELEASE_PRETTY_NAME > OS_RELEASE_BUG_REPORT_URL > etc > (I'm happy to bikeshed the name of the variable prefix). I'm not really into exporting a not-well-defined set of variables. This would mean that e.g. OS_RELEASE_FOO would be explicitly exported if os-release specifies FOO=, and otherwise it would leak from the parent environment. I think it'd be better to bind it to specific variables (possibly all defined os-release vars atm) and clear those that are not specified. > 1.1. Upstream packages that natively read from /etc/os-release will > automatically be supported. > 1.2. Could potentially be in base.eclass. base.eclass is in process of being nuked, so please don't reintroduce that horrible creation. Separate eclasses for specific purposes are the way to go, not huge monsters that do everything. > 2. Introduce a new virtual: virtual/os-branding. I don't mind having a virtual for this but tbh I don't see much of the point in it. Are we going to allow users to switch branding at runtime? ;-) Or is this purely because you find overriding virtual in subdistro cleaner than overriding a package? On one hand, I would agree with that. On the other, that would mean that users will find eternally uninstallable packages due to blockers -- i.e. redundant. > 3. The distro branding package (v1) (providers of virtual/os-branding): > - MUST have NO build dependencies that require execution (this could > be the very first package in a bootstrap). > - MUST install /etc/os-release > - /etc/os-release MUST provide the following values > - NAME, ID, PRETTY_NAME, HOME_URL, BUG_REPORT_URL was also deemed important. > - /etc/os-release MAY provide other values. > - MAY provide hardcoded values for /etc/os-release > - MAY read values from profiles for /etc/os-release > - MAY install any other branding files (logos, artwork, trademark, > notices, etc) I'm not sure if we need to be that specific in what it does. I think that stating that it can go first in bootstrap should be enough ;-). > 4. sys-apps/baselayout: > 4.1. Move all branding pieces OUT of sys-apps/baselayout, into > per-distro packages, that satisfy virtual/os-branding. > 4.2. Depend on virtual/os-branding (maybe implicit via the eclass > above?) Wouldn't it be better to put it into @system? And possibly engage some releng quirks. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgpAaRMrLWYLG.pgp
Description: OpenPGP digital signature
