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

[Guillaume Rousse]

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