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...
