| 1 | GLEP: 42 |
1 | GLEP: 42 |
| 2 | Title: Critical News Reporting |
2 | Title: Critical News Reporting |
| 3 | Version: $Revision: 1.1 $ |
3 | Version: $Revision: 1.4 $ |
| 4 | Author: Ciaran McCreesh <ciaranm@gentoo.org> |
4 | Author: Ciaran McCreesh <ciaranm@gentoo.org> |
| 5 | Last-Modified: $Date: 2005/11/05 03:32:09 $ |
5 | Last-Modified: $Date: 2005/12/11 01:38:18 $ |
| 6 | Status: Draft |
6 | Status: Draft |
| 7 | Type: Standards Track |
7 | Type: Standards Track |
| 8 | Content-Type: text/x-rst |
8 | Content-Type: text/x-rst |
| 9 | Created: 31-October-2005 |
9 | Created: 31-Oct-2005 |
| 10 | Post-Date: 1-November-2005, 5-November-2005 |
10 | Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005 |
| 11 | |
11 | |
| 12 | Abstract |
12 | Abstract |
| 13 | ======== |
13 | ======== |
| 14 | |
14 | |
| 15 | This GLEP proposes a new way of informing users about important updates and news |
15 | This GLEP proposes a new way of informing users about important updates and news |
| 16 | regarding tree-related items. |
16 | regarding tree-related items. |
| 17 | |
17 | |
| 18 | Motivation |
18 | Motivation |
| 19 | ========== |
19 | ========== |
| 20 | |
20 | |
| 21 | There are currently several ways of getting news out to our users, none of them |
21 | Although most package updates are clean and require little user action, |
| 22 | particularly effective: |
22 | occasionally an upgrade requires user intervention during the upgrade process. |
|
|
23 | Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86`` |
|
|
24 | and the ``mysql-5`` database format changes. |
|
|
25 | |
|
|
26 | There are currently several ways of delivering important news items to our |
|
|
27 | users, none of them particularly effective: |
| 23 | |
28 | |
| 24 | * Gentoo Weekly News |
29 | * Gentoo Weekly News |
| 25 | * The ``gentoo-announce`` mailing list |
30 | * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists |
| 26 | * The Gentoo Forums |
31 | * The Gentoo Forums |
| 27 | * The main Gentoo website |
32 | * The main Gentoo website |
| 28 | * RSS feeds of Gentoo news |
33 | * RSS feeds of Gentoo news |
| 29 | |
34 | |
| 30 | A more reliable way of getting news of critical updates out to users is required |
35 | A more reliable way of getting news of critical updates out to users is required |
| 31 | to avoid repeats of the various recent upgrade debacles. This GLEP proposes a |
36 | to avoid repeats of the various recent upgrade debacles. This GLEP proposes a |
| 32 | solution based around pushing news items out to the user via the ``rsync`` tree. |
37 | solution based around pushing news items out to the user via the ``rsync`` tree. |
| 33 | |
38 | |
|
|
39 | .. Important:: This GLEP does not seek to replace or modify ``einfo`` messages |
|
|
40 | which are displayed post-install. That is a separate issue which is handled |
|
|
41 | by ``elog`` [#bug-11359]_. |
|
|
42 | |
| 34 | Requirements |
43 | Requirements |
| 35 | ============ |
44 | ============ |
| 36 | |
45 | |
| 37 | An adequate solution must meet all of the following requirements: |
46 | An adequate solution must meet all of the following requirements: |
| 38 | |
47 | |
| 39 | Preemptive |
48 | Preemptive |
| 40 | Users should be told of changes *before* they break the user's system, |
49 | Users should be told of changes *before* they break a system, not after the |
| 41 | after the damage has already been done. |
50 | damage has already been done. Ideally, the system administrator would be |
|
|
51 | given ample warning to plan difficult upgrades and changes, rather than only |
|
|
52 | being told just before action is necessary. |
| 42 | |
53 | |
| 43 | No user subscription required |
54 | No user subscription required |
| 44 | It has already been demonstrated [#forums-whining]_ that many users do not |
55 | It has already been demonstrated [#forums-apache2]_ that many users do not |
| 45 | read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution which |
56 | read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution which |
| 46 | requires subscription has no advantage over current methods. |
57 | requires subscription has no advantage over current methods. |
| 47 | |
58 | |
| 48 | No user monitoring required |
59 | No user monitoring required |
| 49 | It has already been demonstrated [#forums-whining]_ that many users do not |
60 | It has already been demonstrated [#forums-apache2]_ that many users do not |
| 50 | read news items posted to the Gentoo website, or do not read news items |
61 | read news items posted to the Gentoo website, or do not read news items |
| 51 | until it is too late. A solution that relies upon active monitoring of a |
62 | until it is too late. A solution that relies upon active monitoring of a |
| 52 | particular source has no advantage over current methods. |
63 | particular source has no advantage over current methods. |
| 53 | |
64 | |
| 54 | Relevant |
65 | Relevant |
| … | |
… | |
| 58 | upon users unnecessarily. |
69 | upon users unnecessarily. |
| 59 | |
70 | |
| 60 | Lightweight |
71 | Lightweight |
| 61 | It is not reasonable to expect all users to have an MTA, web browser, email |
72 | It is not reasonable to expect all users to have an MTA, web browser, email |
| 62 | client, cron daemon or text processing suite available on their system. |
73 | client, cron daemon or text processing suite available on their system. |
|
|
74 | Users must not be forced to install unreasonable extra software to be able |
|
|
75 | to read news items. |
| 63 | |
76 | |
| 64 | No privacy violations |
77 | No privacy violations |
| 65 | Users of the solution should not be required to provide information about |
78 | Users of the solution should not be required to provide information about |
| 66 | their systems (for example, IP addresses or installed packages). |
79 | their systems (for example, IP addresses or installed packages). |
| 67 | |
80 | |
| 68 | Multiple delivery method support |
81 | Multiple delivery method support |
| 69 | Some users may wish to view news items via email, some via a terminal and |
82 | Some users may wish to view news items via email, some via a terminal and |
| 70 | some via a web browser. A solution should either support all of these |
83 | some via a web browser. A solution should either support all of these |
| 71 | methods or (better still) make it trivial to write clients for displaying |
84 | methods or (better still) make it simple to write clients for displaying |
| 72 | news items in different ways. |
85 | news items in different ways. |
| 73 | |
86 | |
| 74 | The following characteristics would be desirable: |
87 | The following characteristics would be desirable: |
| 75 | |
88 | |
| 76 | Internationalisable |
89 | Internationalisable |
| 77 | Being able to provide messages in multiple languages may be beneficial. |
90 | Being able to provide messages in multiple languages may be beneficial. |
| 78 | |
91 | |
| 79 | Quality control |
92 | Quality control |
| 80 | There should be some way to ensure that badly written or irrelevant messages |
93 | There should be some way to ensure that badly written or irrelevant messages |
| 81 | are not sent out, for example by inexperienced developers, those whose |
94 | are not sent out, for example by inexperienced developers or those whose |
| 82 | English language skills are below par or morons. |
95 | English language skills are below par. |
| 83 | |
96 | |
| 84 | Simple for developers |
97 | Simple for developers |
| 85 | Posting news items should be as simple as is reasonably possible. |
98 | Posting news items should be as simple as is reasonably possible. |
| 86 | |
99 | |
| 87 | Simple for users |
100 | Simple for users |
| … | |
… | |
| 99 | Overview |
112 | Overview |
| 100 | -------- |
113 | -------- |
| 101 | |
114 | |
| 102 | News items are published and delivered to users as follows: |
115 | News items are published and delivered to users as follows: |
| 103 | |
116 | |
| 104 | 1. A news item is written. The format to be used is described in |
117 | 1. A news item is written. The format to be used is described below. |
| 105 | `News Item File Format`_. |
118 | |
| 106 | 2. The news item is reviewed, following the process described in |
119 | 2. The news item is reviewed, following the process described in |
| 107 | `News Item Quality Control`_. |
120 | `News Item Quality Control`_. |
|
|
121 | |
| 108 | 3. The news item is committed to a CVS (or Subversion [#glep-36]_) repository. |
122 | 3. The news item is committed to a CVS (or Subversion [#glep-36]_) repository. |
| 109 | From here, it is merged with the rsync tree. This is described in `News Item |
123 | From here, it is merged with the rsync tree. This is described in `News Item |
| 110 | Distribution`_. |
124 | Distribution`_. |
| 111 | 4. The news item is merged with the rsync tree. Implementation details of this |
125 | |
| 112 | point are beyond the scope of this GLEP; existing solutions are in place |
|
|
| 113 | for merging GLSAs to the tree. |
|
|
| 114 | 5. Users fetch the news item when they sync. This ensures that the news items in |
126 | 4. Users fetch the news item when they sync. This ensures that the news items in |
| 115 | question are pushed to the user before the user accidentally makes an |
127 | question are pushed to the user before the user accidentally makes an |
| 116 | unwanted change. No changes to the existing rsync process are required by |
128 | unwanted change. No changes to the existing rsync process are required by |
| 117 | this GLEP. |
129 | this GLEP. |
| 118 | 6. Portage filters the news item and, if it is relevant, installs it in a |
130 | |
| 119 | special location to be read by a news item reader. Messages are also |
131 | 5. The package manager filters the news item and, if it is relevant, marks the |
| 120 | displayed to inform the user that news is available. |
132 | news item for reading. The package manager should also display a notice |
|
|
133 | informing the user that there are unread news items. |
|
|
134 | |
| 121 | 7. The news item is handled by the user's choice of news item reader. See `News |
135 | 6. The news item is handled by the user's choice of news item reader. See `News |
| 122 | Item Clients`_. |
136 | Item Clients`_. |
| 123 | |
137 | |
| 124 | News Item File Format |
138 | News Item Identities |
|
|
139 | -------------------- |
|
|
140 | |
|
|
141 | Each news item will have a unique identifier. This identifier will be in the |
|
|
142 | form ``yyyy-mm-dd-short-name``, where ``yyyy`` is the year (e.g. ``2005``), |
|
|
143 | ``mm`` is the month (``01`` through ``12``) and dd is the day of the month |
|
|
144 | (``01`` through ``31``). The ``short-name`` is a very short name describing the |
|
|
145 | news item (e.g. ``yoursql-updates``), consisting only of the characters ``a-z``, |
|
|
146 | ``0-9`` and ``-`` (hyphen). |
|
|
147 | |
|
|
148 | News Item Directories |
| 125 | --------------------- |
149 | --------------------- |
| 126 | |
150 | |
| 127 | Each news item will be represented by a single text file. This file will be |
151 | Each news item will be represented by a directory whose name is the same as the |
| 128 | encoded using UTF-8 for compatibility with and for the same reason as existing |
152 | news item's identifier. |
| 129 | Gentoo documentation [#docs-policy]_ and tree [#glep-31]_ practices. |
|
|
| 130 | |
153 | |
| 131 | The news item will be named in the form ``yyyy-mm-dd-item-name.en.txt``, where |
154 | The directory will contain a file named ``yyyy-mm-dd-short-name.en.txt``, which |
| 132 | ``item-name`` is a very short name (e.g. ``apache-updates``) and ``en`` is the |
155 | contains the text of the news item, in English, in the format described below. |
| 133 | two letter ISO 639 [#iso-639]_ language code for the news item. The short name |
|
|
| 134 | must consist only of characters ``a-z``, ``A-Z``, ``0-9`` and ``-`` (hyphen). |
|
|
| 135 | |
156 | |
| 136 | News items may be signed using GPG. If this is done, a detached signature should |
157 | If a news item is translated, other files named ``yyyy-mm-dd-short-name.xx.txt`` |
| 137 | be used. |
158 | (where ``xx`` is the ISO 639 [#iso-639]_ two letter country code) will also be |
|
|
159 | provided. However, only the English version of a news item is authoritative. |
|
|
160 | This anglocentricity is justified by precedent [#glep-34]_. |
| 138 | |
161 | |
| 139 | The directory and file name rules are designed specifically to allow easy |
162 | News Item Files |
| 140 | sorting by date. |
163 | --------------- |
| 141 | |
164 | |
| 142 | An English (``en``) version must be available for all news items. Other |
165 | A news item file is a text file, encoded using UTF-8 [#rfc-3629]_ for |
| 143 | languages may be provided either by the original author or by other translators |
166 | compatibility with and for the same reasons as existing Gentoo documentation |
| 144 | who have commit access. This anglocentricity is justified on the grounds that |
167 | [#docs-policy]_ and the tree [#glep-31]_. |
| 145 | nobody objected to it with GLEP 34 [#glep-34]_. |
|
|
| 146 | |
168 | |
|
|
169 | News items should be signed with a detached GPG signature: :: |
|
|
170 | |
|
|
171 | gpg --armour --detach-sign ????-??-??-*.??.txt |
|
|
172 | |
| 147 | A news item's content will consist of an RFC 822 [#rfc-822]_ style header |
173 | A news item file's content will consist of an RFC 822 style header [#rfc-822]_ |
| 148 | followed by the main body of the message as plain text. This GLEP defines |
174 | followed by the main body of the message as plain text. This GLEP defines |
| 149 | various optional and mandatory headers. Future GLEPs may propose new headers -- |
175 | various optional and mandatory headers. Future GLEPs may propose new headers — |
| 150 | tools handling these news items must ignore any unrecognised header. |
176 | tools handling these news items must ignore any unrecognised header. |
| 151 | |
177 | |
| 152 | News Item Headers |
178 | News Item Headers |
| 153 | ''''''''''''''''' |
179 | ''''''''''''''''' |
| 154 | |
180 | |
| 155 | The following headers describe the purpose and format of the news item: |
181 | The following headers describe the purpose and format of the news item: |
| 156 | |
182 | |
| 157 | ``Title:`` |
183 | ``Title:`` |
| 158 | A short (maximum 44 characters) descriptive title. Mandatory. |
184 | A short (maximum 44 characters) descriptive title. Mandatory. |
|
|
185 | |
| 159 | ``Author:`` |
186 | ``Author:`` |
| 160 | Author's name and email address, in the form ``Real Name <email@address>``. |
187 | Author's name and email address, in the form ``Real Name <email@address>``. |
| 161 | Mandatory, multiple author fields may be specified if appropriate. |
188 | Mandatory; multiple author headers may be specified if appropriate. |
|
|
189 | |
| 162 | ``Translator:`` |
190 | ``Translator:`` |
| 163 | For translated news items, the translator's name and email address. |
191 | For translated news items, the translator's name and email address. Multiple |
|
|
192 | translator headers may be specified if appropriate. |
|
|
193 | |
| 164 | ``Content-Type:`` |
194 | ``Content-Type:`` |
| 165 | Must be ``text/plain``. Mandatory. |
195 | Must be ``text/plain``. Mandatory. |
|
|
196 | |
| 166 | ``Posted:`` |
197 | ``Posted:`` |
| 167 | Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001). UTC time in |
198 | Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001) for |
| 168 | ``hh-mm-ss +0000`` format may also be included. This field is mandatory. |
199 | compatibility with GLEP 1 [#glep-1]_. UTC time in ``hh-mm-ss +0000`` format |
|
|
200 | may also be included. Mandatory. |
|
|
201 | |
| 169 | ``Version:`` |
202 | ``Revision:`` |
| 170 | Initially 1. Incremented every time a non-trivial change is made. Changes |
203 | Initially 1. Incremented every time a non-trivial change is made. Changes |
| 171 | which require a re-read of the news item should instead use a new news item |
204 | which require a re-read of the news item should instead use a new news item |
| 172 | file. |
205 | file. Mandatory. |
|
|
206 | |
| 173 | ``News-Item-Format:`` |
207 | ``News-Item-Format:`` |
| 174 | Must be ``1.0``. Future revisions to the format may increment the minor |
208 | Must be ``1.0``. Future revisions to the format may increment the minor |
| 175 | number for backwards-compatible changes, or the major number for major |
209 | number for backwards-compatible changes, or the major number for major |
| 176 | changes. |
210 | changes. |
| 177 | |
211 | |
| 178 | The following headers are used for filtering. If none of these headers are |
212 | The following headers are used for filtering: |
| 179 | specified, the news item is displayed for all users. Otherwise, the news item is |
|
|
| 180 | displayed if *at least one* header matches. |
|
|
| 181 | |
213 | |
| 182 | ``Display-If-Installed:`` |
214 | ``Display-If-Installed:`` |
| 183 | A dependency atom or simple package name (for example, |
215 | A dependency atom or simple package name (for example, |
| 184 | ``<dev-lang/php-5_alpha`` or ``net-www/apache``). If the user has the |
216 | ``<dev-lang/php-5_alpha`` or ``net-www/apache``). If the user has the |
| 185 | package specified installed, the news item should be displayed. |
217 | package specified installed, the news item should be displayed. |
| 186 | |
218 | |
| 187 | ``Display-If-Keyword:`` |
219 | ``Display-If-Keyword:`` |
| 188 | A keyword [#glep-22]_ name, for example ``mips``. If the user is on the arch |
220 | A keyword [#glep-22]_ name, for example ``mips`` or ``x86-fbsd``. If the |
| 189 | in question, the news item should be displayed. |
221 | user is on the keyword in question, the news item should be displayed. |
| 190 | |
222 | |
| 191 | ``Display-If-Profile:`` |
223 | ``Display-If-Profile:`` |
| 192 | A profile path, for example ``default-linux/sparc/sparc64/server``. If the |
224 | A profile path, for example ``default-linux/sparc/sparc64/server``. Standard |
| 193 | user is using the exact profile in question, the news item should be |
225 | shell GLOB wildcards may be used. If the user is using the exact profile in |
| 194 | displayed. This header may be used to replace ``deprecated`` files in the |
226 | question, the news item should be displayed. This header may be used to |
| 195 | future. |
227 | replace ``deprecated`` files in the future. |
|
|
228 | |
|
|
229 | .. Note:: When performing package moves, developers must also update any |
|
|
230 | relevant ``Display-If-Installed`` headers in news files. |
|
|
231 | |
|
|
232 | The algorithm used to determine whether a news item is 'relevant' is as |
|
|
233 | follows: |
|
|
234 | |
|
|
235 | * For each ``Display-If-`` header type which occurs at least once: |
|
|
236 | |
|
|
237 | + The news item is not relevant if none of the headers of this type are |
|
|
238 | successfully matched. |
|
|
239 | |
|
|
240 | * Otherwise the news item is relevant. |
|
|
241 | |
|
|
242 | In particular, if no ``Display-If-`` header is specified, a news item will be |
|
|
243 | relevant for all users. |
|
|
244 | |
|
|
245 | This algorithm was chosen because it makes conditions like "display this news |
|
|
246 | item for ``YourSQL`` users who are on ``sparc`` or ``x86-obsd`` relatively |
|
|
247 | simple to specify — it is believed that these kinds of condition are far more |
|
|
248 | likely to occur than "display this news item for people using ``YourSQL``, or |
|
|
249 | for people on ``sparc`` or ``x86-obsd``\" or "display these news items for |
|
|
250 | people who use ``YourSQL`` and who are on both ``sparc`` and ``x86-obsd``\". |
| 196 | |
251 | |
| 197 | News Item Body |
252 | News Item Body |
| 198 | '''''''''''''' |
253 | '''''''''''''' |
| 199 | |
254 | |
| 200 | The header section must be followed by a blank line, then the main body of the |
255 | The header section must be followed by a blank line, then the main body of the |
| 201 | text. |
256 | text. |
| 202 | |
257 | |
| 203 | The text body should be wrapped at 72 characters. No fancy formatting or tab |
258 | The text body should be wrapped at 72 characters. No fancy formatting or tab |
| 204 | characters should be used -- the news item may be being displayed directly to a |
259 | characters should be used — the news item may be being displayed directly to a |
| 205 | terminal. Paragraphs should be separated by two blank lines. |
260 | terminal. Paragraphs should be separated by a blank line. |
| 206 | |
261 | |
| 207 | Hyperlinks may be used to refer to further information (for example, an upgrade |
262 | Hyperlinks may be used to refer to further information (for example, an upgrade |
| 208 | guide). However, the main body of the news item should be descriptive and not |
263 | guide). However, the main body of the news item should be descriptive and not |
| 209 | simply a "read this link" text. It is assumed that the user will have access to |
264 | simply a "read this link" text. It is assumed that the user will have access to |
| 210 | a web browser *somewhere*, but not necessarily on the box which is being |
265 | a web browser *somewhere*, but not necessarily on the box which is being |
| 211 | administrated -- this will be the case on may servers and routers, for example. |
266 | administrated — this will be the case on may servers and routers, for example. |
| 212 | |
267 | |
| 213 | Example News Item |
268 | Example News Item |
| 214 | ''''''''''''''''' |
269 | ''''''''''''''''' |
| 215 | |
270 | |
| 216 | The following hypothetical news item could be used for an upgrade to the |
271 | `This hypothetical news item`__ could be used for an upgrade to the |
| 217 | ``YourSQL`` database format which breaks forward compatibility. It should be |
272 | ``YourSQL`` database format which breaks forward compatibility. |
| 218 | named ``2005-11/2005-11-01-yoursql-upgrades.en.txt``. |
|
|
| 219 | |
273 | |
| 220 | :: |
274 | .. __: glep-0042-extras/example-news-item.txt |
| 221 | |
|
|
| 222 | Title: YourSQL Upgrades from 4.0 to 4.1 |
|
|
| 223 | Author: Ciaran McCreesh <ciaranm@gentoo.org> |
|
|
| 224 | Content-Type: text/plain |
|
|
| 225 | Posted: 01-Nov-2005 |
|
|
| 226 | Display-If-Installed: <dev-db/yoursql-4.1_alpha |
|
|
| 227 | |
|
|
| 228 | YourSQL databases created using YourSQL version 4.0 are incompatible |
|
|
| 229 | with YourSQL version 4.1 or later. There is no reliable way to |
|
|
| 230 | automate the database format conversion, so action from the system |
|
|
| 231 | administrator is required before an upgrade can take place. |
|
|
| 232 | |
|
|
| 233 | Please see the Gentoo YourSQL Upgrade Guide for instructions: |
|
|
| 234 | |
|
|
| 235 | http://www.gentoo.org/doc/en/yoursql-upgrading.xml |
|
|
| 236 | |
|
|
| 237 | Also see the official YourSQL documentation: |
|
|
| 238 | |
|
|
| 239 | http://dev.yoursql.com/doc/refman/4.1/en/upgrading-from-4-0.html |
|
|
| 240 | |
|
|
| 241 | After upgrading, you should also recompile any packages which link |
|
|
| 242 | against YourSQL: |
|
|
| 243 | |
|
|
| 244 | revdep-rebuild --library=libyoursqlclient.so.12 |
|
|
| 245 | |
|
|
| 246 | The revdep-rebuild tool is provided by app-portage/gentoolkit. |
|
|
| 247 | |
275 | |
| 248 | News Item Quality Control |
276 | News Item Quality Control |
| 249 | ------------------------- |
277 | ------------------------- |
| 250 | |
278 | |
| 251 | There have been complaints regarding the comprehensibility of some upgrade |
279 | There have been complaints regarding the comprehensibility of some upgrade |
| 252 | notices and news items in the past. This is understandable -- not every Gentoo |
280 | notices and news items in the past. This is understandable — not every Gentoo |
| 253 | developer speaks English as a first language. However, for the sake of clarity |
281 | developer speaks English as a first language. However, for the sake of clarity, |
| 254 | and professionalism it is important that any language problems be corrected |
282 | professionalism and avoiding making us look like prats, it is important that any |
| 255 | before inflicting a news item upon end users. |
283 | language problems be corrected before inflicting a news item upon end users. |
| 256 | |
284 | |
| 257 | Thus, all proposed news items must be posted to the ``gentoo-dev`` or |
285 | Thus, at least 72 hours before a proposed news item is committed, it must be |
| 258 | ``gentoo-core`` mailing list, and ``Cc:``\ed to ``pr@gentoo.org`` at least 72 |
286 | posted to the ``gentoo-dev`` mailing list and ``Cc:``\ed to ``pr@gentoo.org`` |
| 259 | hours before being committed (exceptions may be made in exceptional |
287 | (exceptions may be made in exceptional circumstances). Any complaints — for |
| 260 | circumstances). Any complaints regarding wording or clarity **must** be |
288 | example regarding wording, clarity or accuracy — **must** be addressed before |
| 261 | addressed before the news item goes live. |
289 | the news item goes live. |
|
|
290 | |
|
|
291 | .. Note:: A previous draft of this GLEP allowed news items to be sent to |
|
|
292 | ``gentoo-core`` instead of ``gentoo-dev``. It is possible that a situation |
|
|
293 | may arise where this will be necessary (for example, a security update which |
|
|
294 | must break backwards compatibility and which cannot be revealed to the public |
|
|
295 | before a given date). |
| 262 | |
296 | |
| 263 | News items must only be for **important** changes that may cause serious upgrade |
297 | News items must only be for **important** changes that may cause serious upgrade |
| 264 | or compatibility problems. Ordinary upgrade messages and non-critical news items |
298 | or compatibility problems. Ordinary upgrade messages and non-critical news items |
| 265 | should remain in ``einfo`` notices. The importance of the message to its |
299 | should remain in ``einfo`` notices. The importance of the message to its |
| 266 | intended audience should be justified with the proposal. |
300 | intended audience should be justified with the proposal. |
| … | |
… | |
| 274 | ---------------------- |
308 | ---------------------- |
| 275 | |
309 | |
| 276 | Server Side |
310 | Server Side |
| 277 | ''''''''''' |
311 | ''''''''''' |
| 278 | |
312 | |
| 279 | News items are to be made available via the Portage tree. This removes any |
313 | News items are to be made available via the standard rsync tree. This removes |
| 280 | need for polling of a remote source. |
314 | any need for polling of a remote source. |
| 281 | |
315 | |
| 282 | A new repository will be created for news items. The type (CVS or Subversion), |
316 | A new repository will be created for news items. The type (CVS or Subversion), |
| 283 | location and access controls on this repository are beyond the scope of this |
317 | location and access controls on this repository are beyond the scope of this |
| 284 | GLEP. |
318 | GLEP. |
| 285 | |
319 | |
| 286 | .. Note:: A previous draft of this GLEP instead used the main ``gentoo-x86`` |
320 | .. Note:: A previous draft of this GLEP instead used the main ``gentoo-x86`` |
| 287 | tree. This was changed following advice from Infrastructure |
321 | tree. This was changed following advice from Infrastructure |
| 288 | [#ramereth-repo]_. Both solutions have the same end result. |
322 | [#ramereth-repo]_. Both solutions have the same end result. |
| 289 | |
323 | |
| 290 | This repository will contain directories named ``yyyy-mm/``, where ``yyyy`` is |
324 | This repository will contain directories named ``yyyy/mm/``, where ``yyyy`` is |
| 291 | the current year and ``mm`` is the current month number (01 for January through |
325 | the current year and ``mm`` is the current month number (01 for January through |
| 292 | 12 for December). This separation will help keep news items more manageable. |
326 | 12 for December). This separation will help keep news items more manageable. |
| 293 | |
327 | |
| 294 | The contents of this repository will automatically be merged with the main rsync |
328 | The contents of this repository will automatically be merged with the main rsync |
| 295 | tree, placing the items under a top-level ``news/`` directory. The method used |
329 | tree, placing the items in a ``metadata/news/`` directory. The method used for |
| 296 | for merging these items is beyond the scope of this GLEP -- a similar setup is |
330 | merging these items is beyond the scope of this GLEP — a similar setup is |
| 297 | already used for merging GLSAs into the rsync tree. |
331 | already used for merging GLSAs into the rsync tree. |
| 298 | |
332 | |
| 299 | .. Note:: The ``profiles/`` directory will *not* be used. This fits in with |
333 | The main rsync tree will **not** use the ``yyyy/mm/`` subdirectory layout. |
| 300 | the Portage team's future plans for ``profiles/`` and ``metadata/`` |
|
|
| 301 | separation. |
|
|
| 302 | |
334 | |
| 303 | Client Side |
335 | Client Side |
| 304 | ''''''''''' |
336 | ''''''''''' |
| 305 | |
337 | |
| 306 | Whenever relevant unread news items are found, ``emerge`` will copy or symlink |
338 | Whenever relevant unread news items are found, the package manager will create a |
| 307 | the news file into ``/var/lib/gentoo/news/``. |
339 | file named ``/var/lib/portage/news/news.unread`` (if it does not already exist) |
|
|
340 | and append the news item identifier (eg ``2005-11-01-yoursql-updates``) on a new |
|
|
341 | line. |
|
|
342 | |
|
|
343 | .. Note:: Future changes to Portage involving support for multiple repositories |
|
|
344 | may require one news list per repository. Assuming repositories have some |
|
|
345 | kind of unique identifier, this file could be named ``news-repoid.unread``. |
| 308 | |
346 | |
| 309 | Notification that new relevant news items will be displayed via the |
347 | Notification that new relevant news items will be displayed via the |
| 310 | ``emerge`` tool in a similar way to the existing "configuration files need |
348 | ``emerge`` tool in a similar way to the existing "configuration files need |
| 311 | updating" messages: |
349 | updating" messages: |
| 312 | |
350 | |
| 313 | :: |
351 | :: |
| 314 | |
352 | |
| 315 | * Important: 3 config files in /etc need updating. |
|
|
| 316 | * Type emerge --help config to learn how to update config files. |
|
|
| 317 | |
|
|
| 318 | * Important: there are 5 unread news items. |
353 | * Important: there are 5 unread news items. |
| 319 | * Type emerge --help news to learn how to read news files. |
354 | * Type emerge --help news to learn how to read news files. |
| 320 | |
355 | |
| 321 | The unread news message will also be displayed immediately after an |
356 | Checks for new news messages should be displayed: |
| 322 | ``emerge sync``. |
|
|
| 323 | |
357 | |
| 324 | Portage may also warn of unread news items using, for example, a red flashy |
358 | * After an ``emerge sync`` |
| 325 | before actions such as merging a package. |
359 | * After an ``emerge --pretend`` |
|
|
360 | * Before an ``emerge <target>`` (which may also include a red warning message) |
| 326 | |
361 | |
| 327 | Portage must keep track of news items which have already been installed to avoid |
362 | The package manager may use a timestamp check file to avoid having to process |
| 328 | repeatedly reinstalling a deleted news item. |
363 | news items unnecessarily. |
|
|
364 | |
|
|
365 | The package manager must keep track of news items that have already been added |
|
|
366 | to the unread list to avoid repeatedly marking a deleted news item. This could |
|
|
367 | be handled via a ``news.skip`` file, but implementation is not specified by this |
|
|
368 | GLEP. |
| 329 | |
369 | |
| 330 | Users who really don't care about news items can use ``rsync_excludes`` to |
370 | Users who really don't care about news items can use ``rsync_excludes`` to |
| 331 | filter out the ``news/`` directory. |
371 | filter out the ``metadata/news/`` directory. |
| 332 | |
372 | |
| 333 | News Item Clients |
373 | News Item Clients |
| 334 | ----------------- |
374 | ----------------- |
| 335 | |
375 | |
| 336 | Once a news item is 'installed', third party tools (or a traditional Unix pager |
376 | Once a news item is marked for reading, third party tools (or traditional core |
| 337 | and ``rm``) can be used to display and view the news files. An ``eselect`` |
377 | Unix tools) can be used to display and view the news files. |
|
|
378 | |
|
|
379 | When a news item is read, its name should be removed from the ``news.unread`` |
|
|
380 | file. News clients may add the name to a ``news.read`` file in the same |
|
|
381 | directory with the same file format. |
|
|
382 | |
| 338 | [#eselect]_ module shall be created as the 'suggested' display tool; other |
383 | An ``eselect`` [#eselect]_ module shall be created as the 'suggested' display |
| 339 | display tools (for example, a news to email forwarder, which would be ideal for |
384 | tool; other display tools (for example, a news to email forwarder, which would |
| 340 | users who sync on a cron) are left as options for those who desire them -- the |
385 | be ideal for users who sync on a ``cron``) are left as options for those who |
| 341 | simple file format make this relatively simple. |
386 | desire them. |
| 342 | |
387 | |
| 343 | News Item Removal |
388 | News Item Removal |
| 344 | ----------------- |
389 | ----------------- |
| 345 | |
390 | |
| 346 | News items can be removed (by removing the news file from the main tree) when |
391 | News items can be removed (by removing the news file from the main tree) when |
| … | |
… | |
| 349 | entries. |
394 | entries. |
| 350 | |
395 | |
| 351 | Integration with Existing Systems |
396 | Integration with Existing Systems |
| 352 | ================================= |
397 | ================================= |
| 353 | |
398 | |
| 354 | It would be trivial to convert these news items into the format used for news |
399 | It would be simple to convert these news items into the format used for news |
| 355 | items on the Gentoo website or posts for the ``gentoo-announce`` mailing list. |
400 | items on the Gentoo website or posts for the ``gentoo-announce`` mailing list. |
| 356 | |
401 | |
| 357 | There is an existing automated tool [#forums-glsa]_ for posting GLSAs to the |
402 | There is an existing automated tool [#forums-glsa]_ for posting GLSAs to the |
| 358 | forums. A similar tool can be used for these news items. |
403 | forums. A similar tool can be used for these news items. |
| 359 | |
404 | |
| … | |
… | |
| 372 | TODO |
417 | TODO |
| 373 | |
418 | |
| 374 | Simple ``eselect`` News Client |
419 | Simple ``eselect`` News Client |
| 375 | ------------------------------ |
420 | ------------------------------ |
| 376 | |
421 | |
| 377 | A demonstration ``eselect`` news display script follows: |
422 | TODO Removed until the exact format details are figured out. |
| 378 | |
|
|
| 379 | :: |
|
|
| 380 | |
|
|
| 381 | # Copyright 1999-2005 Gentoo Foundation |
|
|
| 382 | # Distributed under the terms of the GNU General Public License v2 |
|
|
| 383 | # $Id: glep-0042.txt,v 1.1 2005/11/05 03:32:09 g2boojum Exp $ |
|
|
| 384 | |
|
|
| 385 | DESCRIPTION="Read important Gentoo news items" |
|
|
| 386 | MAINTAINER="ciaranm@gentoo.org" |
|
|
| 387 | SVN_DATE='$Date: 2005/11/05 03:32:09 $' |
|
|
| 388 | VERSION=$(svn_date_to_version "${SVN_DATE}" ) |
|
|
| 389 | |
|
|
| 390 | get_news_item_list() { |
|
|
| 391 | [[ -d "${ROOT}/var/lib/gentoo/news" ]] || return |
|
|
| 392 | ( |
|
|
| 393 | local news |
|
|
| 394 | for news in "${ROOT}/var/lib/gentoo/news/"*.txt ; do |
|
|
| 395 | echo $(basename ${news%%.*} ) |
|
|
| 396 | done |
|
|
| 397 | ) | sort -u |
|
|
| 398 | } |
|
|
| 399 | |
|
|
| 400 | get_filename() { |
|
|
| 401 | local best_lang=${LANG%%_*} lang= filename="${1}" |
|
|
| 402 | [[ -e "/${filename}" ]] || for lang in "${best_lang}" "en" ; do |
|
|
| 403 | filename="${ROOT}/var/lib/gentoo/news/${1}.${lang}.txt" |
|
|
| 404 | [[ -e "${filename}" ]] && break |
|
|
| 405 | done |
|
|
| 406 | [[ -e "${filename}" ]] && echo "${filename}" || die -q "Can't find '${1}'" |
|
|
| 407 | } |
|
|
| 408 | |
|
|
| 409 | get_all_filenames() { |
|
|
| 410 | if [[ -z "${1}" ]] ; then |
|
|
| 411 | echo "${ROOT}/var/lib/gentoo/news/"*.??".txt" |
|
|
| 412 | else |
|
|
| 413 | echo "${ROOT}/var/lib/gentoo/news/${1}."??".txt" |
|
|
| 414 | fi |
|
|
| 415 | } |
|
|
| 416 | |
|
|
| 417 | get_headers() { |
|
|
| 418 | sed -e '/^$/Q' < $(get_filename "${1}" ) |
|
|
| 419 | } |
|
|
| 420 | |
|
|
| 421 | get_body() { |
|
|
| 422 | sed -e '1,/^$/d' < $(get_filename "${1}" ) |
|
|
| 423 | } |
|
|
| 424 | |
|
|
| 425 | get_title() { |
|
|
| 426 | get_headers "${1}" | sed -n -e '/^[Tt]itle: /s/^[^:]\+:[ \t]*//p' |
|
|
| 427 | } |
|
|
| 428 | |
|
|
| 429 | ### list action |
|
|
| 430 | |
|
|
| 431 | ## {{{ list stuff |
|
|
| 432 | describe_list() { |
|
|
| 433 | echo "List available news items" |
|
|
| 434 | } |
|
|
| 435 | |
|
|
| 436 | do_list() { |
|
|
| 437 | write_list_start "Available news items:" |
|
|
| 438 | local empty=yes n=1 |
|
|
| 439 | for news in $(get_news_item_list ) ; do |
|
|
| 440 | write_numbered_list_entry ${n} "$(highlight $(get_title ${news} ) ) (${news})" |
|
|
| 441 | n=$(( n + 1 )) |
|
|
| 442 | done |
|
|
| 443 | } |
|
|
| 444 | ## }}} |
|
|
| 445 | |
|
|
| 446 | ## {{{ show stuff |
|
|
| 447 | describe_show(){ |
|
|
| 448 | echo "Show a news item" |
|
|
| 449 | } |
|
|
| 450 | |
|
|
| 451 | do_show() { |
|
|
| 452 | [[ -z "${1}" ]] && die -q "You didn't tell me which news item to read" |
|
|
| 453 | |
|
|
| 454 | local target=${1} filename= |
|
|
| 455 | if is_number "${target}" && [[ ${target} -ge 1 ]] ; then |
|
|
| 456 | targets=( $(get_news_item_list ) ) |
|
|
| 457 | target=${targets[$(( ${target} - 1 ))]} |
|
|
| 458 | fi |
|
|
| 459 | |
|
|
| 460 | ( |
|
|
| 461 | get_headers "${target}" | grep -v '^Display-If-\|Content-Type:' |
|
|
| 462 | echo |
|
|
| 463 | get_body "${target}" |
|
|
| 464 | ) | ${PAGER:-cat} |
|
|
| 465 | } |
|
|
| 466 | ## }}} |
|
|
| 467 | |
|
|
| 468 | # {{{ delete stuff |
|
|
| 469 | describe_delete() { |
|
|
| 470 | echo "Delete a news item" |
|
|
| 471 | } |
|
|
| 472 | |
|
|
| 473 | do_delete() { |
|
|
| 474 | [[ -z "${1}" ]] && die -q "You didn't tell me which news item to delete" |
|
|
| 475 | |
|
|
| 476 | for target in $@ ; do |
|
|
| 477 | if is_number "${target}" && [[ ${target} -ge 1 ]] ; then |
|
|
| 478 | targets=( $(get_news_item_list ) ) |
|
|
| 479 | target=${targets[$(( ${target} - 1 ))]} |
|
|
| 480 | fi |
|
|
| 481 | |
|
|
| 482 | rm $(get_all_filenames "${target}" ) || die -q "Couldn't delete ${target}" |
|
|
| 483 | done |
|
|
| 484 | } |
|
|
| 485 | # }}} |
|
|
| 486 | |
|
|
| 487 | # {{{ delete-all |
|
|
| 488 | describe_delete-all() { |
|
|
| 489 | echo "Delete all news items" |
|
|
| 490 | } |
|
|
| 491 | |
|
|
| 492 | do_delete-all() { |
|
|
| 493 | rm $(get_all_filenames ) || die -q "Couldn't delete news items" |
|
|
| 494 | } |
|
|
| 495 | # }}} |
|
|
| 496 | |
423 | |
| 497 | Simple News to Mail Forwarder |
424 | Simple News to Mail Forwarder |
| 498 | ----------------------------- |
425 | ----------------------------- |
| 499 | |
426 | |
| 500 | A demonstration shell script which delivers news items via email follows: |
427 | TODO Removed until the exact format details are figured out. |
| 501 | |
|
|
| 502 | :: |
|
|
| 503 | |
|
|
| 504 | #!/bin/bash |
|
|
| 505 | |
|
|
| 506 | to_address="root@localhost" |
|
|
| 507 | mail="mailx" |
|
|
| 508 | best_lang="${LANG%%_*}" |
|
|
| 509 | |
|
|
| 510 | for news in /var/lib/gentoo/news/*.*.txt ; do |
|
|
| 511 | [[ -z "${best_lang}" ]] || news="${news%%.*}.${best_lang}.txt" |
|
|
| 512 | [[ -f "${news}" ]] || news="${news%%.*}.en.txt" |
|
|
| 513 | [[ -f "${news}" ]] || continue |
|
|
| 514 | title=$(sed -n -e '/^Title:/ { s,^[^:]\+:[ \t]\+,,p ; q }' < ${news} ) |
|
|
| 515 | sed -e '1,/^$/ { /^Display-If\|Content-Type/d }' < "${news}" | \ |
|
|
| 516 | ${mail} -s "Gentoo news: ${title}" "${to_address}" && \ |
|
|
| 517 | for file in ${news%%.*}.*.txt ; do rm "${file}" ; done |
|
|
| 518 | done |
|
|
| 519 | |
428 | |
| 520 | Credits |
429 | Credits |
| 521 | ======= |
430 | ======= |
| 522 | |
431 | |
| 523 | The idea behind notifying users of news updates via Portage comes from Stuart |
432 | The idea behind notifying users of news updates via Portage comes from Stuart |
| 524 | Herbert [#stuart-blog]_. |
433 | Herbert [#stuart-blog]_. |
| 525 | |
434 | |
| 526 | Thanks to Lance Albertson, Donnie Berkholz, Grant Goodyear, Brian Harring, Dan |
435 | Thanks to Lance Albertson, Stephen Bennett, Donnie Berkholz, Grant Goodyear, |
| 527 | Meltzer, Paul de Vrieze and Alec Warner for input. Some of the ideas presented |
436 | Brian Harring, Dan Meltzer, Jason Stubbs, Paul de Vrieze and Alec Warner for |
| 528 | here are theirs, others go completely against their suggestions. |
437 | input. Some of the ideas presented here are theirs, others go completely |
|
|
438 | against their suggestions. |
|
|
439 | |
|
|
440 | Example Files |
|
|
441 | ============= |
|
|
442 | |
|
|
443 | TODO Removed until the exact format details are figured out. |
| 529 | |
444 | |
| 530 | References |
445 | References |
| 531 | ========== |
446 | ========== |
| 532 | |
447 | |
|
|
448 | .. [#bug-11359] Bugzilla Bug 11359 |
|
|
449 | "[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging", |
|
|
450 | https://bugs.gentoo.org/show_bug.cgi?id=11359 |
| 533 | .. [#docs-policy] Gentoo XML Guide, Daniel Robbins et al., |
451 | .. [#docs-policy] Gentoo XML Guide, Daniel Robbins et al., |
| 534 | http://www.gentoo.org/doc/en/xml-guide.xml |
452 | http://www.gentoo.org/doc/en/xml-guide.xml |
| 535 | .. [#eselect] eselect modular framework for configuration and |
453 | .. [#eselect] eselect modular framework for configuration and |
| 536 | administration utilities, |
454 | administration utilities, |
| 537 | http://www.gentoo.org/proj/en/eselect/index.xml |
455 | http://www.gentoo.org/proj/en/eselect/index.xml |
| 538 | .. [#forums-glsa] Forums user GLSA, |
456 | .. [#forums-glsa] Forums user GLSA, |
| 539 | http://forums.gentoo.org/profile.php?mode=viewprofile&u=55648 |
457 | http://forums.gentoo.org/profile.php?mode=viewprofile&u=55648 |
| 540 | .. [#forums-whining] Forums thread "Gentoo Apache2 Config Change Idiocy", |
458 | .. [#forums-apache2] Forums thread "Gentoo Apache2 Config Change Idiocy", |
| 541 | http://forums.gentoo.org/viewtopic-t-384368.html |
459 | http://forums.gentoo.org/viewtopic-t-384368.html |
|
|
460 | .. [#glep-1] GLEP 1: "GLEP Purpose and Guidelines", Grant Goodyear, |
|
|
461 | http://www.gentoo.org/proj/en/glep/glep-0001.html |
| 542 | .. [#glep-22] GLEP 22: "New "keyword" system to incorporate various |
462 | .. [#glep-22] GLEP 22: "New "keyword" system to incorporate various |
| 543 | userlands/kernels/archs", Grant Goodyear, |
463 | userlands/kernels/archs", Grant Goodyear, |
| 544 | http://www.gentoo.org/proj/en/glep/glep-0022.html |
464 | http://www.gentoo.org/proj/en/glep/glep-0022.html |
| 545 | .. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran |
465 | .. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran |
| 546 | McCreesh, |
466 | McCreesh, |
| … | |
… | |
| 553 | .. [#iso-639] ISO 639 "Code for the representation of names of languages" |
473 | .. [#iso-639] ISO 639 "Code for the representation of names of languages" |
| 554 | .. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance |
474 | .. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance |
| 555 | Albertson, |
475 | Albertson, |
| 556 | http://marc.theaimsgroup.com/?l=gentoo-dev&m=113111585907703&w=2 |
476 | http://marc.theaimsgroup.com/?l=gentoo-dev&m=113111585907703&w=2 |
| 557 | .. [#rfc-822] RFC 822 "Standard for the format of ARPA Internet text messages" |
477 | .. [#rfc-822] RFC 822 "Standard for the format of ARPA Internet text messages" |
|
|
478 | .. [#rfc-3629] RFC 3629: "UTF-8, a transformation format of ISO 10646" |
|
|
479 | http://www.ietf.org/rfc/rfc3629.txt |
| 558 | .. [#stuart-blog] "Favouring an automatic news mechanism", Stuart Herbert, |
480 | .. [#stuart-blog] "Favouring an automatic news mechanism", Stuart Herbert, |
| 559 | http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic_news_mechanism |
481 | http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic_news_mechanism |
| 560 | |
482 | |
| 561 | Copyright |
483 | Copyright |
| 562 | ========= |
484 | ========= |