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.