Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 440214 (first-time-messages) - [tracker] packages with emerge messages that can be improved by checking the previous installed version
Summary: [tracker] packages with emerge messages that can be improved by checking the ...
Status: UNCONFIRMED
Alias: first-time-messages
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords: Tracker
Depends on: 440218 440424 440444 440452 440476 440478 440484 440494 440538 440598 457598 509994 440216 440410 440412 440414 440416 440418 440420 440422 440426 440428 440430 440432 440434 440436 440438 440440 440442 440446 440448 440450 440454 440456 440458 440460 440462 440464 440466 440468 440470 440472 440474 440480 440482 440486 440488 440490 440492 440496 440498 440500 440502 440504 440506 440508 440510 440512 440514 440516 440518 440520 440522 440526 440530 440532 440534 440536 440540 440542 440544 440546 440548 440550 440552 440554 440556 440558 440560 440562 440564 440566 440568 440570 440572 440574 440576 440578 440580 440582 440584 440586 440588 440590 440592 440594 440596 440600 456068 457594 457596 458624 509382 509384 509386 509996 510000 510784 554722
Blocks:
  Show dependency tree
 
Reported: 2012-10-30 07:40 UTC by poletti.marco
Modified: 2015-07-13 09:41 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description poletti.marco 2012-10-30 07:40:43 UTC
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
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-10-31 15:15:38 UTC
(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.
Comment 2 Michael Weber (RETIRED) gentoo-dev 2012-10-31 19:25:15 UTC
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.
Comment 3 poletti.marco 2012-10-31 21:08:13 UTC
(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.
Comment 4 Xake 2012-10-31 22:24:00 UTC
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)?
Comment 5 Ryan Hill (RETIRED) gentoo-dev 2012-11-01 02:14:01 UTC
(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.
Comment 6 poletti.marco 2012-11-01 07:01:42 UTC
(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.
Comment 7 poletti.marco 2012-11-01 07:05:26 UTC
(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.
Comment 8 poletti.marco 2012-11-01 21:05:06 UTC
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).