| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 15/12/16 15:49, Robin H. Johnson wrote: |
| 5 |
> I do really agree that how we offer branding should be covered in |
| 6 |
> a GLEP, and be very easy for downstream offshoots of Gentoo to |
| 7 |
> follow. This would prevent future concerns like the Ubuntu branding |
| 8 |
> / modified VM spats. |
| 9 |
> |
| 10 |
> [snip awilfox's superb proposal; I agree with all of the reasons |
| 11 |
> and outcomes, but think a little bit more structure & flexibility |
| 12 |
> are needed]. |
| 13 |
|
| 14 |
I posted it to the list with the express intent that I welcomed |
| 15 |
improvements. I'm glad that the community seems to agree this needs |
| 16 |
to be done, and that we want to get it right the first time. |
| 17 |
|
| 18 |
|
| 19 |
> 0. This proposal is centered around using os-release, as a |
| 20 |
> cross-distribution model. |
| 21 |
|
| 22 |
I am interested how this will work :) |
| 23 |
|
| 24 |
|
| 25 |
> 1. ebuilds: Add eclass to export all variables from /etc/os-release |
| 26 |
> with a prefix: OS_RELEASE_ID OS_RELEASE_NAME |
| 27 |
> OS_RELEASE_PRETTY_NAME OS_RELEASE_BUG_REPORT_URL etc (I'm happy to |
| 28 |
> bikeshed the name of the variable prefix). |
| 29 |
|
| 30 |
|
| 31 |
OS_RELEASE_* seems fine to me. |
| 32 |
|
| 33 |
|
| 34 |
> 1.1. Upstream packages that natively read from /etc/os-release |
| 35 |
> will automatically be supported. |
| 36 |
|
| 37 |
|
| 38 |
Yes, this thankfully includes most modern KDE 5 and XFCE packages. |
| 39 |
Still, KDE 4 needs to be told in configure/CMake. |
| 40 |
|
| 41 |
|
| 42 |
> 1.2. Could potentially be in base.eclass. |
| 43 |
|
| 44 |
|
| 45 |
What does it do when /etc/os-release doesn't exist? Would Portage |
| 46 |
still be usable? I am imagining such a thing as: "I accidentally |
| 47 |
deleted /etc! I can recreate most of it using emerge -e world |
| 48 |
though." Also, crossdev / embedded images. |
| 49 |
|
| 50 |
|
| 51 |
> 2. Introduce a new virtual: virtual/os-branding. |
| 52 |
|
| 53 |
|
| 54 |
This is an interesting idea. |
| 55 |
|
| 56 |
|
| 57 |
> 3. The distro branding package (v1) (providers of |
| 58 |
> virtual/os-branding): - MUST have NO build dependencies that |
| 59 |
> require execution (this could be the very first package in a |
| 60 |
> bootstrap). |
| 61 |
|
| 62 |
|
| 63 |
Ah, I see now. That would make much sense. Since it would likely be |
| 64 |
static files anyway, it would probably need no DEPEND= at all, I would |
| 65 |
hope. |
| 66 |
|
| 67 |
|
| 68 |
> - MUST install /etc/os-release - /etc/os-release MUST provide the |
| 69 |
> following values - NAME, ID, PRETTY_NAME, HOME_URL, |
| 70 |
|
| 71 |
|
| 72 |
Where does OS_RELEASE_BUG_REPORT_URL come from? Does it use HOME_URL |
| 73 |
if BUG_REPORT_URL is not set? I suppose that would be acceptable. |
| 74 |
|
| 75 |
|
| 76 |
> - /etc/os-release MAY provide other values. - MAY provide hardcoded |
| 77 |
> values for /etc/os-release - MAY read values from profiles for |
| 78 |
> /etc/os-release - MAY install any other branding files (logos, |
| 79 |
> artwork, trademark, notices, etc) |
| 80 |
|
| 81 |
|
| 82 |
It could RDEPEND on sys-boot/ logos and such. Not sure that large |
| 83 |
desktop backgrounds and the like should be required on small embedded |
| 84 |
images that have no displays though. Perhaps artwork could be in IUSE. |
| 85 |
|
| 86 |
|
| 87 |
> 4. sys-apps/baselayout: 4.1. Move all branding pieces OUT of |
| 88 |
> sys-apps/baselayout, into per-distro packages, that satisfy |
| 89 |
> virtual/os-branding. |
| 90 |
|
| 91 |
|
| 92 |
That is also interesting. So other distros could then use the Gentoo |
| 93 |
baselayout package without having /etc/gentoo-release files and so on. |
| 94 |
Good idea. |
| 95 |
|
| 96 |
|
| 97 |
> 4.2. Depend on virtual/os-branding (maybe implicit via the eclass |
| 98 |
> above?) |
| 99 |
> |
| 100 |
|
| 101 |
|
| 102 |
Hmm. If it goes in base.eclass, everything would depend on it. |
| 103 |
Including virtual/os-branding itself? Not sure how Portage |
| 104 |
could/would handle such a thing. |
| 105 |
|
| 106 |
If there were to be a branding.eclass, it would certainly make things |
| 107 |
much easier. It would also give more explicit knowledge of what |
| 108 |
packages were using it, instead of grepping the tree for ${DISTRO} and |
| 109 |
the like, you could simply see what packages inherit branding. |
| 110 |
|
| 111 |
If work lightens up I will try to get something hammered out by |
| 112 |
Friday. Otherwise, I will probably have something by the weekend. |
| 113 |
|
| 114 |
Thanks! |
| 115 |
|
| 116 |
Warm regards, |
| 117 |
- --arw |
| 118 |
|
| 119 |
|
| 120 |
- -- |
| 121 |
A. Wilcox (awilfox) |
| 122 |
Project Lead, Adélie Linux |
| 123 |
http://adelielinux.org |
| 124 |
-----BEGIN PGP SIGNATURE----- |
| 125 |
Version: GnuPG v2 |
| 126 |
|
| 127 |
iQIcBAEBCAAGBQJYUx3sAAoJEMspy1GSK50UFF0QAMOxiiqwX0uR5Ubx7ZHQj5qL |
| 128 |
5iHK/KPQW9tR4vumtCRy/xppK2xvQ7uQbyZWsVekfUmqji/YH3+KoKyy0ffuFryA |
| 129 |
DpEQ7Gar/J1dXLainriTxfpFxuDHMO2OEzcUxpYD7PJ5snj9I7ED1e5KtxZnW3XQ |
| 130 |
lpccCBKbtcmiEum3bODGwFr3PI7awpiZZBRZZgDpP+Am8ibnMeYuST4ROcem58RO |
| 131 |
7b8TQIcVMQmtJLpZSc64WFwOZ22SRRBz4TXkaWrUC+6+swhSXqWuMkMwSYYZVmBt |
| 132 |
8HIMKBOrS25bi4BEIft/+p68DVeYJLGp3d2SAM3DBlkgDV2FsicHp9+m/DTZXPYA |
| 133 |
4JUvv+n/sROudEeUj2MP9j5XMarSl2uZHoNeBKIM64AtxL05hdXKj+bXofCEIgXh |
| 134 |
4/TPq275cMIMfWFHuNy1/zh/DYJ0emE5RekFx1oCj4i37+HU72moft6Ndtdkxz/p |
| 135 |
FlwRonpouE4mBQ8H4wPkJ3wWPaVpL6k33adPRKnycjid1JhA+a9Qnsr1ZoILzfc6 |
| 136 |
6ieNEtSHiX6C5CbrEIlkaiAhzgGwUlq+dkjakIWBibPHUSJgg8tU2fyzaIO+o90A |
| 137 |
Z2Y5uikUFW5GCRLTAPC5e7Tfx0yfGhyR5CSWkkyexAE86YDj/72BU967UfnQznEp |
| 138 |
rQkL+Ax+1C1FJSj5JIa2 |
| 139 |
=7adt |
| 140 |
-----END PGP SIGNATURE----- |
Archives