Some packages provide error messages that are only relevant when upgrading from a specific version or only when doing a fresh install of the package (no upgrade). For example, a message saying "From version 4.0 feature X changed" should only be displayed when the previous version is <4.0. Also, messages providing a quick-start for how to use a package should not be displayed again every time the package is upgraded. This bug is the tracker version of Bug 440178. Reproducible: Always
(In reply to comment #0) > Some packages provide error messages that are only relevant when upgrading > from a specific version or only when doing a fresh install of the package > (no upgrade). > > For example, a message saying "From version 4.0 feature X changed" should > only be displayed when the previous version is <4.0. Have you considered the case when user had an old version, removed it and some time later installed a new version? The config files were likely preserved, and the messages may still be relevant. > Also, messages providing a quick-start for how to use a package should not > be displayed again every time the package is upgraded. Maybe. But there are cases when it may be relevant: - when the message was specific to a USE flag which was not enabled before, - when user reinstalls the same version just to see the messages again. Not that I'm opposed. I just have my doubts I'd like someone to address.
It would make sense to test, if the config file is missing. An `! has_version net-dns/dnssec-tools` does not test for the presence or absence of an config-file, just if it was presently installed. So you test is wrong. The test makes no sense in src_* functions, since it might be distributed and pkg_* functions get relevant. It might make sense to test for the config file in ${EROOT} inside of pkg_postinst, but it might be relocated. So, you end up looking for the config file to be specified inside /etc/conf.d/${PN}, sure.
(In reply to comment #1) > [...] > Have you considered the case when user had an old version, removed it and > some time later installed a new version? The config files were likely > preserved, and the messages may still be relevant. Yes, this could happen. So I guess that we should always display such messages when installing a package from scratch. > > Also, messages providing a quick-start for how to use a package should not > > be displayed again every time the package is upgraded. > > Maybe. But there are cases when it may be relevant: > > - when the message was specific to a USE flag which was not enabled before, This can (and in my opinion should) be checked. > - when user reinstalls the same version just to see the messages again. This is something that is not supported by the commands I suggested. And yes, the user may expect to get the same messages every time a package is re-emerged. By displaying the messages only once (and no more for updates), we break this expectation. An (ugly, IMHO) workaround would be to always display all messages when a package is re-emerged (with the same version). However, this may be even more surprising for the user, since re-emerging a package after an update may show more messages than the update itself. > Not that I'm opposed. I just have my doubts I'd like someone to address. Sure. I always appreciate constructive criticism.
How does this handle if a message is added to a revision? Say a message is specified to only show up when a package is freshly installed. And it was added to package-x.y-r1. Will it show up for a user that had package-x.y installed? For example "We know xyz does not work, and we have no intention of adding it. Do not file bugs about it." set to show up for first-time-install will show this message? How about added to the same revision (tolerated IIRC because it does not change the installed files)?
(In reply to comment #0) > For example, a message saying "From version 4.0 feature X changed" should > only be displayed when the previous version is <4.0. I agree with this. We have some packages that refer to changes/breakages that haven't been relevant in years (eg. pleas to run revdep-rebuild for a soname change that happened a dozen versions ago). > Also, messages providing a quick-start for how to use a package should not > be displayed again every time the package is upgraded. But not this. The info may be beneficial, and the cost is effectively zero.
(In reply to comment #4) > How does this handle if a message is added to a revision? > > Say a message is specified to only show up when a package is freshly > installed. And it was added to package-x.y-r1. Will it show up for a user > that had package-x.y installed? > > For example "We know xyz does not work, and we have no intention of adding > it. Do not file bugs about it." set to show up for first-time-install will > show this message? > How about added to the same revision (tolerated IIRC because it does not > change the installed files)? In both cases, the message wouldn't show up. The message also wouldn't show up if the user has package-(x-1) installed and upgrades to package-x. Maybe for such messages the version check is not the right thing to do, and we should have some system in place (say elog-handler) that remembers which messages the user has seen and which not. So the ebuild developers could mark a message as "Just show this once" if they want, and the user would be able to get all the messages for a package when they want, without re-emerging (say with "elog-handler get package-x"). I guess that we should move this discussion to the mailing-list, rather than here in this bug. If someone does, please CC me.
(In reply to comment #5) > [...] > > Also, messages providing a quick-start for how to use a package should not > > be displayed again every time the package is upgraded. > > But not this. The info may be beneficial, and the cost is effectively zero. The motivation behind these bugs is that a user updating his/her own system currently gets a lot of such messages, and risks missing the important ones IMHO. As I said in comment 6, the way I suggested may not be the best one to solve this problem.
As William Hubbs noted in bug 440410, the has_version check sould not be done in pkg_postinst - if it's really needed it should be run in pkg_preinst and stored as a flag, and that flag should be used later in pkg_postinst. As several people noted, another possibility is to check REPLACING_VERSIONS instead (if only the version needs to be checked, and not the use flags).
