-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 15/12/16 17:03, Michał Górny wrote: > On Thu, 15 Dec 2016 21:49:15 +0000 "Robin H. Johnson" > <robb...@gentoo.org> wrote: >> 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.
I hadn't realised the wording of this sentence when I replied. Yes, that seems like a bad way to go; it should have a set of variables that will be exported to ebuilds. And perhaps fall back to the profile for anything not provided. >> 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. As I said in last email, I plan to make 'branding.eclass'. No base. >> 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. As someone who is running a subdistro: virtuals cause me even more pain than real packages, as I have to constantly chase || dep list, and when it is updated, normally there is no version bump (it is eternally virtual/whatever-0 or virtual/whatever-1) so I have to go in and change again. I agreed simply because package.provided exists. But I already have to 'override' sys-apps/baselayout, due partially to licensing concerns and partially to the fact it has Gentoo branding everywhere. >> 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. @system has no guaranteed merge order. It would be better to make it implicit via eclass, for two reasons I can think of: 1) It will pull in the package before it is needed. Guaranteed. 2) On embedded/crossdev, the only package in @system is busybox. So there is no branding present. That means that virtual/os-branding would be useless bloat, unless and until a package that uses it is installed (at which case it could be installed anyway). Just my two cents. Thank you. Best, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYU0FUAAoJEMspy1GSK50UWvoP/AiNspWMoqTz9WXEDOhSWdPe XEMSvjnMHoDvc7ETpKWiCPHx6bOB+S/B/sGwdSU4H7hHCg5a5JukzHToXwaVZRgm pO+W5084kJIRSMDsOo5xRN8B9tQqfBdmZwvsJHJ7pGHrP38m6iLm04FTbn1kbc/Q CyCAStRmTs0NROcJFXEIZAyDJohdvhWBk2CLKcou2zhcLmZDwMuOJaHM85FK+7fg 9+DDrehBfbIM+YuSKz52A++sUwRTofnkGPzGycfL+UGmbEB6JrU6tSem5YyQpxe2 UZzsmJUzvY75hh1yvqeh7Ye6DPY2l0UYFkY24SVO/QlSkqXr9qJNYo8gJ7Un7y/4 aGpQnbNgus/dioHvTLcQnWeipBiGCal3EBJEkh9hKzPrJsLmpn2Ogh/+OJsxdw4S qMQCgqA3vB9wDig5JatSootGSPyAOAEOyQ3I8fkpj96bz2T7pgxX9wvGnkfKXIVY CTqdYJjQCAnxfFBujoN6AUiTMVaXBhewS7O6TOLJiszVqhlAsjbLeza/xY4vrpgG VzmakLygqkmY3+xgqLcgqFOkazAr6ZldxaDERVV0lvRcs8sr+3ycXTRnpudB8EdT x5rvwsUaLqn0OWjTGnPdsmkt/WgWw2vEfCdnMqjW84VeQCjMHBbikLJmj+oVaqoB q7MlTp0uHpQQ51X4ESy/ =lGeb -----END PGP SIGNATURE-----
