[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement

[Guillaume Rousse]

Le 04/01/2012 16:53, Luc Menut a écrit :
> Hello,
>
> We have recently discussed here about task-obsolete.
> http://www.mail-archive.com/mageia-dev@mageia.org/msg09762.html
> https://bugs.mageia.org/show_bug.cgi?id=3786
>
> I like the idea.
> But I think that we need to inform the user about the package(s) that we
> will obsolete and remove on his system (and why: security, ..).
> So I tried to use README.*.urpmi to do this.
> But I found that currently, urpmi and rpmdrake don't handle very well
> optional README.*.urpmi (%ghost); they always display information's
> screen, even if the file doesn't exist.
>
> So, I propose here 2 enhancements for README.*.urpmi (POC patch for
> urpm/install.pm, and task-obsolete.spec in attachment):
>
> 1) add support for optional README.*.urpmi (%ghost in spec):
> This will allow to build this README.*.urpmi at install time in %pre,
> %post or %trigger only when it's necessary.
That will create files on the system unknown from rpm database, and 
unknown from urpmi too.

> One use case from the recent past in my mind:
> we have no way to inform users that still use nspluginwrapper + i586
> flashplayer on x86_64 (and only them), that this is now deprecated and
> they should replace the i586 by the x86_64 flashplayer,
> https://bugs.mageia.org/show_bug.cgi?id=2146#c22
> https://bugs.mageia.org/show_bug.cgi?id=2146#c25
>
> 2) handle README.*.(obsolete|deprecated).urpmi
> In order to display informations about the deprecated or obsoleted
> package(s), I suggest to handle 2 new kinds of README.*.urpmi:
> - README."nameObsoletedPackage".obsolete.urpmi to inform about the
> package we obsolete by task-obsolete
> e.g. java-1.6.0-sun*, https://bugs.mageia.org/show_bug.cgi?id=3101
>
> - README."nameDeprecatedPackage".deprecated.urpmi to inform about
> package that we considere as deprecated, but we have no reason (no
> vulnerability, security, ...) to force uninstallation (task-deprecated?).
>
> What do you think ?
Rather than focusing on shiny automatic display mechanisms, I'd rather 
work on information content.

We currently have a ugly mix of README.mdk (4), README.mdv (5), 
README.urpmi (46), README.update.urpmi (1), eventually others, without 
any clue about their internal consistency. The last one I saw 
(roundcubemail) had quite a bunch of informations about package upgrade, 
but nothing about post-installation, for instance. Some of them use very 
personal tone (Hello, this is Oden, your favorite apache manager, 
advising you to visit my own web site to get additional modules, 
cheers), while other are purely technical instructions (run mysql with 
this file to create the database).

We also have some packages (such as postfix) advising users to read this 
file in their description:
PLEASE READ THE %{_defaultdocdir}/%{name}/README.MDK FILE.

So, today we have heterogeneous information cluttered in a gazillion 
different microfiles, a subset of them being automatically displayed 
during installation (ruining urpmi mass update output).

Here are a few proposal of mines to make the situation better:
- use a unique file name, enforced by convention, rather than references 
in package description, the same way Debian does with README.debian
- display its content only in graphical context: command-line users 
usually know about this kind of convention to get information themselves
- use standardised file content and markup to allow rpmdrake and other 
graphical tools to achieve the same kind of selection than file 
splitting today
- define some kind of policy of what should be there, and what should 
not, to achieve minimal consistency
-- 
BOFH excuse #187:

Reformatting Page. Wait...