Ok, new draft. Changes are as follows:
* mysql-4.1, not -5.
* Added einfo, ewarn to the list of methods currently used
* Added + and : to the allowed news item IDs, to match package name
policy (Kugelfang thought we might need, say, a libstdc++ news item at
some point)
* Changed /var/lib/portage to /var/lib/gentoo
* The news file is now named 'news-magic-chicken.*'. News clients are
to use a wildcard rather than hardcoding magic-chicken.
* Added emerge --ask thingie
* news.read is now mandatory for interactive clients, and ignored for
gateway clients
Read the whole thing before commenting please.
--
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
GLEP: 42
Title: Critical News Reporting
Version: $Revision: $
Author: Ciaran McCreesh [EMAIL PROTECTED]
Last-Modified: $Date: $
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 31-Oct-2005
Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005
Abstract
This GLEP proposes a new way of informing users about important updates and news
regarding tree-related items.
Motivation
==
Although most package updates are clean and require little user action,
occasionally an upgrade requires user intervention during the upgrade process.
Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86``
and the ``mysql-4.1`` database format changes.
There are currently several ways of delivering important news items to our
users, none of them particularly effective:
* Gentoo Weekly News
* The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists
* The Gentoo Forums
* The main Gentoo website
* RSS feeds of Gentoo news
* ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst``
A more reliable way of getting news of critical updates out to users is required
to avoid repeats of the various recent upgrade debacles. This GLEP proposes a
solution based around pushing news items out to the user via the ``rsync`` tree.
.. Important:: This GLEP does not seek to replace or modify ``einfo`` messages
which are displayed post-install. That is a separate issue which is handled
by ``elog`` [#bug-11359]_.
Requirements
An adequate solution must meet all of the following requirements:
Preemptive
Users should be told of changes *before* they break a system, not after the
damage has already been done. Ideally, the system administrator would be
given ample warning to plan difficult upgrades and changes, rather than only
being told just before action is necessary.
No user subscription required
It has already been demonstrated [#forums-apache2]_ that many users do not
read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution which
requires subscription has no advantage over current methods.
No user monitoring required
It has already been demonstrated [#forums-apache2]_ that many users do not
read news items posted to the Gentoo website, or do not read news items
until it is too late. A solution that relies upon active monitoring of a
particular source has no advantage over current methods.
Relevant
System administrators who do not use a particular package should not have to
read news items which affect purely that package. Some news items may be of
relevance to most or all users, but those that are not should not be forced
upon users unnecessarily.
Lightweight
It is not reasonable to expect all users to have an MTA, web browser, email
client, cron daemon or text processing suite available on their system.
Users must not be forced to install unreasonable extra software to be able
to read news items.
No privacy violations
Users of the solution should not be required to provide information about
their systems (for example, IP addresses or installed packages).
Multiple delivery method support
Some users may wish to view news items via email, some via a terminal and
some via a web browser. A solution should either support all of these
methods or (better still) make it simple to write clients for displaying
news items in different ways.
The following characteristics would be desirable:
Internationalisable
Being able to provide messages in multiple languages may be beneficial.
Quality control
There should be some way to ensure that badly written or irrelevant messages
are not sent out, for example by inexperienced developers or those whose
English language skills are below par.
Simple for developers
Posting news items should be as simple as is reasonably possible.
Simple for users
Reading relevant news items should be as simple as is reasonably possible.
Compatibility with existing and future news sources
A news system would ideally be able to be integrated with existing news
sources (for example, Forums, GWN,
