And rely on README.gentoo file if people want to review it later. I am referring to this message I see on every update: elog "If you are upgrading from a previous kernel, you may be interested" elog "in the following document:" elog " - General upgrade guide: http://www.gentoo.org/doc/en/kernel-upgrade.xml" I can do the changes myself if you want Reproducible: Always
Created attachment 345380 [details] readme.gentoo.patch This patch will be part of a series of patches that will be sent to the mailing lists and committed all at once to the tree in the near future.
Thanks Tom
As said on the mailing list, I didn't continue to apply this patch. A consensus for this is needed in order to change it from its current behavior. Unless the eclass can be changed to show it on the first upgrade and also be made more clear from the eclass that the file is installed / available on the systems
FORCE_PRINT_ELOG variable can be used to show the elog message in certain conditions... but I don't know how to detect the "first upgrade" situation (will CC portage team to see if they know any possible solution) Regarding informing users about README.gentoo files, not sure what to do: 1. Add a note in Handbook teaching users to look for this files when available. 2. Use a news item 3. Change eclass to show an "einfo" message when this file is installed I would opt for first option :/
(In reply to comment #4) > FORCE_PRINT_ELOG variable can be used to show the elog message in certain > conditions... but I don't know how to detect the "first upgrade" situation > (will CC portage team to see if they know any possible solution) So, you want to detect the first time that it is upgraded after the user has unpacked a stage3 for installation purposes? Since stage3 doesn't contain kernel sources, isn't the "first upgrade" the same as the "first install", which is when $REPLACING_VERSIONS is empty?
If you want the first upgrade after the first install, then you could have the package install a file containing a count of how many times the package has been upgraded. For example: counter_path=var/lib/${PN}-${SLOT}-UPGRADE-COUNTER if [[ -f ${ROOT}${counter_path} ]] ; then
(In reply to comment #4) > FORCE_PRINT_ELOG variable can be used to show the elog message in certain > conditions... but I don't know how to detect the "first upgrade" situation > (will CC portage team to see if they know any possible solution) > > Regarding informing users about README.gentoo files, not sure what to do: > 1. Add a note in Handbook teaching users to look for this files when > available. > 2. Use a news item > 3. Change eclass to show an "einfo" message when this file is installed > > I would opt for first option :/ @docs-team, could a note be added to Handbook explaining people that some packages install README.gentoo (like README.fedora, opensuse, debian...) files inside their respective /usr/share/doc dirs explaining them how to configure the packages and so?
it's up to the ebuilds to print out documentation/reading instructions via elog/einfo/whatever. we're not going to tell users to blindly "ls" and "cat" their way through every mandir that gets installed on the off-chance there's something in it specific to gentoo users. that info really does belong up-front in elog, every time, so that it's always printed to the console and users don't have to have a mindset of browsing to all the dirs for every package that gets updated.
Then, maybe an elog message can be appended the first time ebuild is installed informing people :/
+ 18 May 2013; Pacho Ramos <pacho@gentoo.org> readme.gentoo.eclass: + Add a note informing people a file is being installed for future reference, + http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg58207.html +
I'll try to push this through again when doing a new patch set for the eclass. I'm kind of afraid this is going to get complaints again since it doesn't let the user know that the file exists on each emerge; your patch went through though, so that's a solid ground to assume that its behavior is accepted by a majority. It be kind of odd for people not to complain on your patch but do complain on mine; if they do that again, I'll point it out right away. We'll see how it goes, unless you think yourself we should show it every time...
I think current readme.gentoo.eclass is more than enough... my only doubt if that, if kernel sources are already installed by stage3, people wouldn't ever see any message as kernel sources won't ever be installed by first time, but I think that Zac's solution could resolve that problem
The stage3 shouldn't contain kernel sources, since catalyst is suppose to use --depclean --with-bdeps=n to remove them from the stage before it creates the tarball. I'm not even sure why kernel sources get pulled in to the stage3 build, because I've put gentoo-sources into package.provided for my local stage builds and it works fine.
Pacho, Can readme.gentoo-r1.eclass take parameters and support README.gentoo-5.10.bz2 Then we could show the message at 5.10.0 but not anything >. Then start again with 5.11.0. Thoughts?
Is not possible to set FORCE_PRINT_ELOG in the case of previous version being older than a version? Like that we wouldn't need to copy multiple times the same README.gentoo file
(In reply to Pacho Ramos from comment #15) > Is not possible to set FORCE_PRINT_ELOG in the case of previous version > being older than a version? Like that we wouldn't need to copy multiple > times the same README.gentoo file Are you talking about utilizing REPLACING_VERSIONS ?
I was thinking on it yes :)
(In reply to Pacho Ramos from comment #17) > I was thinking on it yes :) kernels don't replace other kernels Would that work ?
Ah, true :S But maybe has_version could be used to try to guess if user is moving from, for example, 5.10.x (checking if it has already any of its version installed) or not :/
(In reply to Pacho Ramos from comment #19) > Ah, true :S > > But maybe has_version could be used to try to guess if user is moving from, > for example, 5.10.x (checking if it has already any of its version > installed) or not :/ Seems like a lot of code to prevent an elog message? Would you reconsider the parameter re
(In reply to Mike Pagano from comment #20) > (In reply to Pacho Ramos from comment #19) > > Ah, true :S > > > > But maybe has_version could be used to try to guess if user is moving from, > > for example, 5.10.x (checking if it has already any of its version > > installed) or not :/ > > Seems like a lot of code to prevent an elog message? > Would you reconsider the parameter request above ?
Sure, but I am not sure if I will be able to work on trying to implement it soon. Of course if you have a patch, I would really welcome it
(In reply to Mike Pagano from comment #14) > Pacho, > > Can readme.gentoo-r1.eclass take parameters and support > > README.gentoo-5.10.bz2 > > Then we could show the message at 5.10.0 but not anything >. > > Then start again with 5.11.0. > > Thoughts? Maybe current logic for README_GENTOO_SUFFIX or SLOT could work for you (around line 65 in the eclass)
(In reply to Pacho Ramos from comment #23) > (In reply to Mike Pagano from comment #14) > > Pacho, > > > > Can readme.gentoo-r1.eclass take parameters and support > > > > README.gentoo-5.10.bz2 > > > > Then we could show the message at 5.10.0 but not anything >. > > > > Then start again with 5.11.0. > > > > Thoughts? > > Maybe current logic for README_GENTOO_SUFFIX or SLOT could work for you > (around line 65 in the eclass) Already tried that. I'll see what I can with your eclass, maybe I'll open a Feature bug on that
