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

Thu Jan 5 13:54:10 CET 2012

Le 04/01/2012 20:13, Luc Menut a écrit :
+> Le 04/01/2012 17:20, Guillaume Rousse a écrit :
+>>> 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.
+>
+> nope, %ghost files are known from rpm database.
+> rpm -qpl task-obsolete-1-1.mga2.noarch.rpm
+> /usr/share/doc/task-obsolete
+> /usr/share/doc/task-obsolete/README.null-dummy.obsolete.urpmi
+> /usr/share/doc/task-obsolete/README.null.obsolete.urpmi
+Then the database will always contains entries for some files that only 
+will potentially exist on the systeme. The whole idea of conditionnaly 
+creating files in post-installation seems a bad idea.
+
+>> Rather than focusing on shiny automatic display mechanisms, I'd rather
+>> work on information content.
+>
+> we can|should do both.
+>
+> [...]
+>>
+>> 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
+>
+> I'm not particularly attached at the current system, but I find it works
+> rather well.
+> If we want that users read informations, the information should be
+> relevant in the context (too many informations, kill information);
+Indeed, that's why I suggest using standardised documentation templates 
+and conventions, rather than automated mecanisms.
+
+> e.g. it's useless (personnaly, I consider it's bad) to display
+> information about install when we update a package, and vice versa (I
+> don't know debian, and if the unique file README.debian allow this).
+The README.debian is just a plain old reference text file, and is never 
+automatically displayed. Debian does however has a powerful 
+post-installation interactive mecanism (debconf), which is usually used 
+for configuration, but could also get used for this kind of 
+context-specific information.
+
+I completly agree on the generic idea of making information access 
+easier. But I wouldn't reduce this to just extracting the minimal subset 
+of relevant information so as to display it automatically. Especially if 
+the suggested implementation involves messing with rpm idea of installed 
+files, and also make information access more complex for users as myself 
+who prefer to read plain old documentation files manually.
+
+This kind of context-dependant logic should better get implemented in 
+the installer rather than individual packages. And even in that case, 
+the added value of a technical solution someone will have to maintain
+over a simple remark in flashplayer plugin package documentation is 
+discussable.
+-- 
+BOFH excuse #62:
+
+need to wrap system in aluminum foil to fix problem
+