1 |
g2boojum |
1.1 |
GLEP: 42 |
2 |
|
|
Title: Critical News Reporting |
3 |
|
|
Version: $Revision: $ |
4 |
|
|
Author: Ciaran McCreesh <ciaranm@gentoo.org> |
5 |
|
|
Last-Modified: $Date: $ |
6 |
|
|
Status: Draft |
7 |
|
|
Type: Standards Track |
8 |
|
|
Content-Type: text/x-rst |
9 |
|
|
Created: 31-October-2005 |
10 |
|
|
Post-Date: 1-November-2005, 5-November-2005 |
11 |
|
|
|
12 |
|
|
Abstract |
13 |
|
|
======== |
14 |
|
|
|
15 |
|
|
This GLEP proposes a new way of informing users about important updates and news |
16 |
|
|
regarding tree-related items. |
17 |
|
|
|
18 |
|
|
Motivation |
19 |
|
|
========== |
20 |
|
|
|
21 |
|
|
There are currently several ways of getting news out to our users, none of them |
22 |
|
|
particularly effective: |
23 |
|
|
|
24 |
|
|
* Gentoo Weekly News |
25 |
|
|
* The ``gentoo-announce`` mailing list |
26 |
|
|
* The Gentoo Forums |
27 |
|
|
* The main Gentoo website |
28 |
|
|
* RSS feeds of Gentoo news |
29 |
|
|
|
30 |
|
|
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 |
32 |
|
|
solution based around pushing news items out to the user via the ``rsync`` tree. |
33 |
|
|
|
34 |
|
|
Requirements |
35 |
|
|
============ |
36 |
|
|
|
37 |
|
|
An adequate solution must meet all of the following requirements: |
38 |
|
|
|
39 |
|
|
Preemptive |
40 |
|
|
Users should be told of changes *before* they break the user's system, |
41 |
|
|
after the damage has already been done. |
42 |
|
|
|
43 |
|
|
No user subscription required |
44 |
|
|
It has already been demonstrated [#forums-whining]_ that many users do not |
45 |
|
|
read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution which |
46 |
|
|
requires subscription has no advantage over current methods. |
47 |
|
|
|
48 |
|
|
No user monitoring required |
49 |
|
|
It has already been demonstrated [#forums-whining]_ that many users do not |
50 |
|
|
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 |
52 |
|
|
particular source has no advantage over current methods. |
53 |
|
|
|
54 |
|
|
Relevant |
55 |
|
|
System administrators who do not use a particular package should not have to |
56 |
|
|
read news items which affect purely that package. Some news items may be of |
57 |
|
|
relevance to most or all users, but those that are not should not be forced |
58 |
|
|
upon users unnecessarily. |
59 |
|
|
|
60 |
|
|
Lightweight |
61 |
|
|
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. |
63 |
|
|
|
64 |
|
|
No privacy violations |
65 |
|
|
Users of the solution should not be required to provide information about |
66 |
|
|
their systems (for example, IP addresses or installed packages). |
67 |
|
|
|
68 |
|
|
Multiple delivery method support |
69 |
|
|
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 |
71 |
|
|
methods or (better still) make it trivial to write clients for displaying |
72 |
|
|
news items in different ways. |
73 |
|
|
|
74 |
|
|
The following characteristics would be desirable: |
75 |
|
|
|
76 |
|
|
Internationalisable |
77 |
|
|
Being able to provide messages in multiple languages may be beneficial. |
78 |
|
|
|
79 |
|
|
Quality control |
80 |
|
|
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 |
82 |
|
|
English language skills are below par or morons. |
83 |
|
|
|
84 |
|
|
Simple for developers |
85 |
|
|
Posting news items should be as simple as is reasonably possible. |
86 |
|
|
|
87 |
|
|
Simple for users |
88 |
|
|
Reading relevant news items should be as simple as is reasonably possible. |
89 |
|
|
|
90 |
|
|
Compatibility with existing and future news sources |
91 |
|
|
A news system would ideally be able to be integrated with existing news |
92 |
|
|
sources (for example, Forums, GWN, the main Gentoo website) without |
93 |
|
|
excessive difficulty. Similarly, easy interoperation with any future news |
94 |
|
|
sources should not be precluded. |
95 |
|
|
|
96 |
|
|
Specification |
97 |
|
|
============= |
98 |
|
|
|
99 |
|
|
Overview |
100 |
|
|
-------- |
101 |
|
|
|
102 |
|
|
News items are published and delivered to users as follows: |
103 |
|
|
|
104 |
|
|
1. A news item is written. The format to be used is described in |
105 |
|
|
`News Item File Format`_. |
106 |
|
|
2. The news item is reviewed, following the process described in |
107 |
|
|
`News Item Quality Control`_. |
108 |
|
|
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 |
110 |
|
|
Distribution`_. |
111 |
|
|
4. The news item is merged with the rsync tree. Implementation details of this |
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 |
115 |
|
|
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 |
117 |
|
|
this GLEP. |
118 |
|
|
6. Portage filters the news item and, if it is relevant, installs it in a |
119 |
|
|
special location to be read by a news item reader. Messages are also |
120 |
|
|
displayed to inform the user that news is available. |
121 |
|
|
7. The news item is handled by the user's choice of news item reader. See `News |
122 |
|
|
Item Clients`_. |
123 |
|
|
|
124 |
|
|
News Item File Format |
125 |
|
|
--------------------- |
126 |
|
|
|
127 |
|
|
Each news item will be represented by a single text file. This file will be |
128 |
|
|
encoded using UTF-8 for compatibility with and for the same reason as existing |
129 |
|
|
Gentoo documentation [#docs-policy]_ and tree [#glep-31]_ practices. |
130 |
|
|
|
131 |
|
|
The news item will be named in the form ``yyyy-mm-dd-item-name.en.txt``, where |
132 |
|
|
``item-name`` is a very short name (e.g. ``apache-updates``) and ``en`` is the |
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 |
|
|
|
136 |
|
|
News items may be signed using GPG. If this is done, a detached signature should |
137 |
|
|
be used. |
138 |
|
|
|
139 |
|
|
The directory and file name rules are designed specifically to allow easy |
140 |
|
|
sorting by date. |
141 |
|
|
|
142 |
|
|
An English (``en``) version must be available for all news items. Other |
143 |
|
|
languages may be provided either by the original author or by other translators |
144 |
|
|
who have commit access. This anglocentricity is justified on the grounds that |
145 |
|
|
nobody objected to it with GLEP 34 [#glep-34]_. |
146 |
|
|
|
147 |
|
|
A news item's content will consist of an RFC 822 [#rfc-822]_ style header |
148 |
|
|
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 -- |
150 |
|
|
tools handling these news items must ignore any unrecognised header. |
151 |
|
|
|
152 |
|
|
News Item Headers |
153 |
|
|
''''''''''''''''' |
154 |
|
|
|
155 |
|
|
The following headers describe the purpose and format of the news item: |
156 |
|
|
|
157 |
|
|
``Title:`` |
158 |
|
|
A short (maximum 44 characters) descriptive title. Mandatory. |
159 |
|
|
``Author:`` |
160 |
|
|
Author's name and email address, in the form ``Real Name <email@address>``. |
161 |
|
|
Mandatory, multiple author fields may be specified if appropriate. |
162 |
|
|
``Translator:`` |
163 |
|
|
For translated news items, the translator's name and email address. |
164 |
|
|
``Content-Type:`` |
165 |
|
|
Must be ``text/plain``. Mandatory. |
166 |
|
|
``Posted:`` |
167 |
|
|
Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001). UTC time in |
168 |
|
|
``hh-mm-ss +0000`` format may also be included. This field is mandatory. |
169 |
|
|
``Version:`` |
170 |
|
|
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 |
172 |
|
|
file. |
173 |
|
|
``News-Item-Format:`` |
174 |
|
|
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 |
176 |
|
|
changes. |
177 |
|
|
|
178 |
|
|
The following headers are used for filtering. If none of these headers are |
179 |
|
|
specified, the news item is displayed for all users. Otherwise, the news item is |
180 |
|
|
displayed if *at least one* header matches. |
181 |
|
|
|
182 |
|
|
``Display-If-Installed:`` |
183 |
|
|
A dependency atom or simple package name (for example, |
184 |
|
|
``<dev-lang/php-5_alpha`` or ``net-www/apache``). If the user has the |
185 |
|
|
package specified installed, the news item should be displayed. |
186 |
|
|
|
187 |
|
|
``Display-If-Keyword:`` |
188 |
|
|
A keyword [#glep-22]_ name, for example ``mips``. If the user is on the arch |
189 |
|
|
in question, the news item should be displayed. |
190 |
|
|
|
191 |
|
|
``Display-If-Profile:`` |
192 |
|
|
A profile path, for example ``default-linux/sparc/sparc64/server``. If the |
193 |
|
|
user is using the exact profile in question, the news item should be |
194 |
|
|
displayed. This header may be used to replace ``deprecated`` files in the |
195 |
|
|
future. |
196 |
|
|
|
197 |
|
|
News Item Body |
198 |
|
|
'''''''''''''' |
199 |
|
|
|
200 |
|
|
The header section must be followed by a blank line, then the main body of the |
201 |
|
|
text. |
202 |
|
|
|
203 |
|
|
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 |
205 |
|
|
terminal. Paragraphs should be separated by two blank lines. |
206 |
|
|
|
207 |
|
|
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 |
209 |
|
|
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 |
211 |
|
|
administrated -- this will be the case on may servers and routers, for example. |
212 |
|
|
|
213 |
|
|
Example News Item |
214 |
|
|
''''''''''''''''' |
215 |
|
|
|
216 |
|
|
The following hypothetical news item could be used for an upgrade to the |
217 |
|
|
``YourSQL`` database format which breaks forward compatibility. It should be |
218 |
|
|
named ``2005-11/2005-11-01-yoursql-upgrades.en.txt``. |
219 |
|
|
|
220 |
|
|
:: |
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 |
|
|
|
248 |
|
|
News Item Quality Control |
249 |
|
|
------------------------- |
250 |
|
|
|
251 |
|
|
There have been complaints regarding the comprehensibility of some upgrade |
252 |
|
|
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 |
254 |
|
|
and professionalism it is important that any language problems be corrected |
255 |
|
|
before inflicting a news item upon end users. |
256 |
|
|
|
257 |
|
|
Thus, all proposed news items must be posted to the ``gentoo-dev`` or |
258 |
|
|
``gentoo-core`` mailing list, and ``Cc:``\ed to ``pr@gentoo.org`` at least 72 |
259 |
|
|
hours before being committed (exceptions may be made in exceptional |
260 |
|
|
circumstances). Any complaints regarding wording or clarity **must** be |
261 |
|
|
addressed before the news item goes live. |
262 |
|
|
|
263 |
|
|
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 |
265 |
|
|
should remain in ``einfo`` notices. The importance of the message to its |
266 |
|
|
intended audience should be justified with the proposal. |
267 |
|
|
|
268 |
|
|
.. Important:: The filtering system means that it is appropriate to send out |
269 |
|
|
news items which are aimed at users of an uncommon package or architecture. |
270 |
|
|
Thus, the justification should be in the form "this message is important to |
271 |
|
|
YourSQL users because ...", not "YourSQL is important because ...". |
272 |
|
|
|
273 |
|
|
News Item Distribution |
274 |
|
|
---------------------- |
275 |
|
|
|
276 |
|
|
Server Side |
277 |
|
|
''''''''''' |
278 |
|
|
|
279 |
|
|
News items are to be made available via the Portage tree. This removes any |
280 |
|
|
need for polling of a remote source. |
281 |
|
|
|
282 |
|
|
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 |
284 |
|
|
GLEP. |
285 |
|
|
|
286 |
|
|
.. Note:: A previous draft of this GLEP instead used the main ``gentoo-x86`` |
287 |
|
|
tree. This was changed following advice from Infrastructure |
288 |
|
|
[#ramereth-repo]_. Both solutions have the same end result. |
289 |
|
|
|
290 |
|
|
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 |
292 |
|
|
12 for December). This separation will help keep news items more manageable. |
293 |
|
|
|
294 |
|
|
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 |
296 |
|
|
for merging these items is beyond the scope of this GLEP -- a similar setup is |
297 |
|
|
already used for merging GLSAs into the rsync tree. |
298 |
|
|
|
299 |
|
|
.. Note:: The ``profiles/`` directory will *not* be used. This fits in with |
300 |
|
|
the Portage team's future plans for ``profiles/`` and ``metadata/`` |
301 |
|
|
separation. |
302 |
|
|
|
303 |
|
|
Client Side |
304 |
|
|
''''''''''' |
305 |
|
|
|
306 |
|
|
Whenever relevant unread news items are found, ``emerge`` will copy or symlink |
307 |
|
|
the news file into ``/var/lib/gentoo/news/``. |
308 |
|
|
|
309 |
|
|
Notification that new relevant news items will be displayed via the |
310 |
|
|
``emerge`` tool in a similar way to the existing "configuration files need |
311 |
|
|
updating" messages: |
312 |
|
|
|
313 |
|
|
:: |
314 |
|
|
|
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. |
319 |
|
|
* Type emerge --help news to learn how to read news files. |
320 |
|
|
|
321 |
|
|
The unread news message will also be displayed immediately after an |
322 |
|
|
``emerge sync``. |
323 |
|
|
|
324 |
|
|
Portage may also warn of unread news items using, for example, a red flashy |
325 |
|
|
before actions such as merging a package. |
326 |
|
|
|
327 |
|
|
Portage must keep track of news items which have already been installed to avoid |
328 |
|
|
repeatedly reinstalling a deleted news item. |
329 |
|
|
|
330 |
|
|
Users who really don't care about news items can use ``rsync_excludes`` to |
331 |
|
|
filter out the ``news/`` directory. |
332 |
|
|
|
333 |
|
|
News Item Clients |
334 |
|
|
----------------- |
335 |
|
|
|
336 |
|
|
Once a news item is 'installed', third party tools (or a traditional Unix pager |
337 |
|
|
and ``rm``) can be used to display and view the news files. An ``eselect`` |
338 |
|
|
[#eselect]_ module shall be created as the 'suggested' display tool; other |
339 |
|
|
display tools (for example, a news to email forwarder, which would be ideal for |
340 |
|
|
users who sync on a cron) are left as options for those who desire them -- the |
341 |
|
|
simple file format make this relatively simple. |
342 |
|
|
|
343 |
|
|
News Item Removal |
344 |
|
|
----------------- |
345 |
|
|
|
346 |
|
|
News items can be removed (by removing the news file from the main tree) when |
347 |
|
|
they are no longer relevant, if they are made obsolete by a future news item or |
348 |
|
|
after a long period of time. This is the same as the method used for ``updates`` |
349 |
|
|
entries. |
350 |
|
|
|
351 |
|
|
Integration with Existing Systems |
352 |
|
|
================================= |
353 |
|
|
|
354 |
|
|
It would be trivial 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. |
356 |
|
|
|
357 |
|
|
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. |
359 |
|
|
|
360 |
|
|
Backwards Compatibility |
361 |
|
|
======================= |
362 |
|
|
|
363 |
|
|
Backwards compatibility is not a concern here. Existing tools will simply ignore |
364 |
|
|
the ``news/`` directory. |
365 |
|
|
|
366 |
|
|
Reference Implementation |
367 |
|
|
======================== |
368 |
|
|
|
369 |
|
|
Portage Code |
370 |
|
|
------------ |
371 |
|
|
|
372 |
|
|
TODO |
373 |
|
|
|
374 |
|
|
Simple ``eselect`` News Client |
375 |
|
|
------------------------------ |
376 |
|
|
|
377 |
|
|
A demonstration ``eselect`` news display script follows: |
378 |
|
|
|
379 |
|
|
:: |
380 |
|
|
|
381 |
|
|
# Copyright 1999-2005 Gentoo Foundation |
382 |
|
|
# Distributed under the terms of the GNU General Public License v2 |
383 |
|
|
# $Id: $ |
384 |
|
|
|
385 |
|
|
DESCRIPTION="Read important Gentoo news items" |
386 |
|
|
MAINTAINER="ciaranm@gentoo.org" |
387 |
|
|
SVN_DATE='$Date: $' |
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 |
|
|
|
497 |
|
|
Simple News to Mail Forwarder |
498 |
|
|
----------------------------- |
499 |
|
|
|
500 |
|
|
A demonstration shell script which delivers news items via email follows: |
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 |
|
|
|
520 |
|
|
Credits |
521 |
|
|
======= |
522 |
|
|
|
523 |
|
|
The idea behind notifying users of news updates via Portage comes from Stuart |
524 |
|
|
Herbert [#stuart-blog]_. |
525 |
|
|
|
526 |
|
|
Thanks to Lance Albertson, Donnie Berkholz, Grant Goodyear, Brian Harring, Dan |
527 |
|
|
Meltzer, Paul de Vrieze and Alec Warner for input. Some of the ideas presented |
528 |
|
|
here are theirs, others go completely against their suggestions. |
529 |
|
|
|
530 |
|
|
References |
531 |
|
|
========== |
532 |
|
|
|
533 |
|
|
.. [#docs-policy] Gentoo XML Guide, Daniel Robbins et al., |
534 |
|
|
http://www.gentoo.org/doc/en/xml-guide.xml |
535 |
|
|
.. [#eselect] eselect modular framework for configuration and |
536 |
|
|
administration utilities, |
537 |
|
|
http://www.gentoo.org/proj/en/eselect/index.xml |
538 |
|
|
.. [#forums-glsa] Forums user GLSA, |
539 |
|
|
http://forums.gentoo.org/profile.php?mode=viewprofile&u=55648 |
540 |
|
|
.. [#forums-whining] Forums thread "Gentoo Apache2 Config Change Idiocy", |
541 |
|
|
http://forums.gentoo.org/viewtopic-t-384368.html |
542 |
|
|
.. [#glep-22] GLEP 22: "New "keyword" system to incorporate various |
543 |
|
|
userlands/kernels/archs", Grant Goodyear, |
544 |
|
|
http://www.gentoo.org/proj/en/glep/glep-0022.html |
545 |
|
|
.. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran |
546 |
|
|
McCreesh, |
547 |
|
|
http://www.gentoo.org/proj/en/glep/glep-0031.html |
548 |
|
|
.. [#glep-34] GLEP 34: "Per-Category metadata.xml Files", Ciaran McCreesh, |
549 |
|
|
http://www.gentoo.org/proj/en/glep/glep-0034.html |
550 |
|
|
.. [#glep-36] GLEP 36: "Subversion/CVS for Gentoo Hosted Projects", Aaron |
551 |
|
|
Walker, |
552 |
|
|
http://www.gentoo.org/proj/en/glep/glep-0036.html |
553 |
|
|
.. [#iso-639] ISO 639 "Code for the representation of names of languages" |
554 |
|
|
.. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance |
555 |
|
|
Albertson, |
556 |
|
|
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" |
558 |
|
|
.. [#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 |
560 |
|
|
|
561 |
|
|
Copyright |
562 |
|
|
========= |
563 |
|
|
|
564 |
|
|
This document has been placed in the public domain. |
565 |
|
|
|
566 |
|
|
.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et : |