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


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

Luc

--
Luc Menut

Reply via email to