Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
On 05.01.2012 14:54, Guillaume Rousse wrote: > 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. Those already exist for all localization which is not installed in your system. However, I do agree it is significantly worse in this case as the user can wonder why a *documentation* file that seems important by its filename is missing. -- Anssi Hannula
Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
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
Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
Le 04/01/2012 20:26, Anssi Hannula a écrit :
On 04.01.2012 17:53, Luc Menut wrote:
[...]
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.
> 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
This change seems reasonable.
> 2) handle README.*.(obsolete|deprecated).urpmi
[...]
I don't understand the need for this one, isn't this just the same as
README.urpmi?
You are right, we don't need this part; each trigger can add its message
in task-obsolete/README.urpmi.
we just need the following patch to handle %ghost README.urpmi :
Index: urpm/install.pm
===
--- urpm/install.pm (revision 2572)
+++ urpm/install.pm (working copy)
@@ -109,6 +109,7 @@
foreach my $file ($pkg->files) {
my ($kind) = $file =~ m!/README([^/]*)\.urpmi$! or next;
+ -r $file or next;
my $valid;
if ($kind eq '') {
$valid = 1;
--
Luc Menut
Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
On 04.01.2012 18:20, Guillaume Rousse wrote: > 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 +1 except for the 2nd point; I do want any important information to be shown automatically. For example, I don't check the documentation of each and every package on each and every update for upgrade information. I also agree Johnny, all the information should be shown in the end of the urpmi run, not in the middle of installing packages where one may not notice them. -- Anssi Hannula
Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
On 04.01.2012 17:53, Luc Menut wrote: > 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. > 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 This change seems reasonable. > 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?). I don't understand the need for this one, isn't this just the same as README.urpmi? > What do you think ? -- Anssi Hannula
Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
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
Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
On Wednesday 04 January 2012 17:20, Guillaume Rousse wrote: > a subset of them being automatically displayed during installation (ruining > urpmi mass update output). I have an idea regarding this. What about storing all those notices in a file during install that one can review after the (automatic) update is complete. Then one can read it in calm and peace without having to remember to having to use " |tee autoinstall.txt" and what not, or reading like mad durng install and remember all info that is briefly displayed before it's scrolled away. I have no idea on how hard it might be to implement thou. Just thinking out loud. ;-)= -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
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...
