| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 15/12/16 17:03, Michał Górny wrote: |
| 5 |
> On Thu, 15 Dec 2016 21:49:15 +0000 "Robin H. Johnson" |
| 6 |
> <robbat2@g.o> wrote: |
| 7 |
>> 1. ebuilds: Add eclass to export all variables from |
| 8 |
>> /etc/os-release with a prefix: OS_RELEASE_ID OS_RELEASE_NAME |
| 9 |
>> OS_RELEASE_PRETTY_NAME OS_RELEASE_BUG_REPORT_URL etc (I'm happy |
| 10 |
>> to bikeshed the name of the variable prefix). |
| 11 |
> |
| 12 |
> I'm not really into exporting a not-well-defined set of variables. |
| 13 |
> This would mean that e.g. OS_RELEASE_FOO would be explicitly |
| 14 |
> exported if os-release specifies FOO=, and otherwise it would leak |
| 15 |
> from the parent environment. |
| 16 |
> |
| 17 |
> I think it'd be better to bind it to specific variables (possibly |
| 18 |
> all defined os-release vars atm) and clear those that are not |
| 19 |
> specified. |
| 20 |
|
| 21 |
|
| 22 |
I hadn't realised the wording of this sentence when I replied. Yes, |
| 23 |
that seems like a bad way to go; it should have a set of variables |
| 24 |
that will be exported to ebuilds. And perhaps fall back to the |
| 25 |
profile for anything not provided. |
| 26 |
|
| 27 |
|
| 28 |
>> 1.1. Upstream packages that natively read from /etc/os-release |
| 29 |
>> will automatically be supported. 1.2. Could potentially be in |
| 30 |
>> base.eclass. |
| 31 |
> |
| 32 |
> base.eclass is in process of being nuked, so please don't |
| 33 |
> reintroduce that horrible creation. Separate eclasses for specific |
| 34 |
> purposes are the way to go, not huge monsters that do everything. |
| 35 |
|
| 36 |
|
| 37 |
As I said in last email, I plan to make 'branding.eclass'. No base. |
| 38 |
|
| 39 |
|
| 40 |
>> 2. Introduce a new virtual: virtual/os-branding. |
| 41 |
> |
| 42 |
> I don't mind having a virtual for this but tbh I don't see much of |
| 43 |
> the point in it. Are we going to allow users to switch branding at |
| 44 |
> runtime? ;-) |
| 45 |
> |
| 46 |
> Or is this purely because you find overriding virtual in subdistro |
| 47 |
> cleaner than overriding a package? On one hand, I would agree with |
| 48 |
> that. On the other, that would mean that users will find eternally |
| 49 |
> uninstallable packages due to blockers -- i.e. redundant. |
| 50 |
|
| 51 |
|
| 52 |
As someone who is running a subdistro: virtuals cause me even more |
| 53 |
pain than real packages, as I have to constantly chase || dep list, |
| 54 |
and when it is updated, normally there is no version bump (it is |
| 55 |
eternally virtual/whatever-0 or virtual/whatever-1) so I have to go in |
| 56 |
and change again. I agreed simply because package.provided exists. |
| 57 |
|
| 58 |
But I already have to 'override' sys-apps/baselayout, due partially to |
| 59 |
licensing concerns and partially to the fact it has Gentoo branding |
| 60 |
everywhere. |
| 61 |
|
| 62 |
|
| 63 |
>> 4. sys-apps/baselayout: 4.1. Move all branding pieces OUT of |
| 64 |
>> sys-apps/baselayout, into per-distro packages, that satisfy |
| 65 |
>> virtual/os-branding. 4.2. Depend on virtual/os-branding (maybe |
| 66 |
>> implicit via the eclass above?) |
| 67 |
> |
| 68 |
> Wouldn't it be better to put it into @system? And possibly engage |
| 69 |
> some releng quirks. |
| 70 |
|
| 71 |
|
| 72 |
@system has no guaranteed merge order. It would be better to make it |
| 73 |
implicit via eclass, for two reasons I can think of: |
| 74 |
|
| 75 |
1) It will pull in the package before it is needed. Guaranteed. |
| 76 |
2) On embedded/crossdev, the only package in @system is busybox. So |
| 77 |
there is no branding present. That means that virtual/os-branding |
| 78 |
would be useless bloat, unless and until a package that uses it is |
| 79 |
installed (at which case it could be installed anyway). |
| 80 |
|
| 81 |
|
| 82 |
Just my two cents. Thank you. |
| 83 |
|
| 84 |
|
| 85 |
Best, |
| 86 |
- --arw |
| 87 |
|
| 88 |
|
| 89 |
- -- |
| 90 |
A. Wilcox (awilfox) |
| 91 |
Project Lead, Adélie Linux |
| 92 |
http://adelielinux.org |
| 93 |
-----BEGIN PGP SIGNATURE----- |
| 94 |
Version: GnuPG v2 |
| 95 |
|
| 96 |
iQIcBAEBCAAGBQJYU0FUAAoJEMspy1GSK50UWvoP/AiNspWMoqTz9WXEDOhSWdPe |
| 97 |
XEMSvjnMHoDvc7ETpKWiCPHx6bOB+S/B/sGwdSU4H7hHCg5a5JukzHToXwaVZRgm |
| 98 |
pO+W5084kJIRSMDsOo5xRN8B9tQqfBdmZwvsJHJ7pGHrP38m6iLm04FTbn1kbc/Q |
| 99 |
CyCAStRmTs0NROcJFXEIZAyDJohdvhWBk2CLKcou2zhcLmZDwMuOJaHM85FK+7fg |
| 100 |
9+DDrehBfbIM+YuSKz52A++sUwRTofnkGPzGycfL+UGmbEB6JrU6tSem5YyQpxe2 |
| 101 |
UZzsmJUzvY75hh1yvqeh7Ye6DPY2l0UYFkY24SVO/QlSkqXr9qJNYo8gJ7Un7y/4 |
| 102 |
aGpQnbNgus/dioHvTLcQnWeipBiGCal3EBJEkh9hKzPrJsLmpn2Ogh/+OJsxdw4S |
| 103 |
qMQCgqA3vB9wDig5JatSootGSPyAOAEOyQ3I8fkpj96bz2T7pgxX9wvGnkfKXIVY |
| 104 |
CTqdYJjQCAnxfFBujoN6AUiTMVaXBhewS7O6TOLJiszVqhlAsjbLeza/xY4vrpgG |
| 105 |
VzmakLygqkmY3+xgqLcgqFOkazAr6ZldxaDERVV0lvRcs8sr+3ycXTRnpudB8EdT |
| 106 |
x5rvwsUaLqn0OWjTGnPdsmkt/WgWw2vEfCdnMqjW84VeQCjMHBbikLJmj+oVaqoB |
| 107 |
q7MlTp0uHpQQ51X4ESy/ |
| 108 |
=lGeb |
| 109 |
-----END PGP SIGNATURE----- |
Archives