[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
From:       "A. Wilcox" <awilfox () adelielinux ! org>
Date:       2016-12-16 1:20:20
Message-ID: 58534154.6050603 () adelielinux ! org
[Download RAW message or body]

-----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"
> <robbat2@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-----

[prev in list] [next in list] [prev in thread] [next in thread]