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

Wed Jan 4 17:20:59 CET 2012

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