On Thu, August 22, 2013 08:39, Alan McKinnon wrote: > On 22/08/2013 08:20, J. Roeleveld wrote: >> On Wed, August 21, 2013 22:02, Neil Bothwick wrote: >>> On Wed, 21 Aug 2013 11:50:57 -0400, Tanstaafl wrote: >>> > > [snip] > >>> No one has demonstrated that it can. An initramfs isn't magic, it >>> caries out a couple of trivial tasks before switching to the real root >>> partition. >> >> The issue mentioned was an example. It was also: >> 1) The only one I can remember from the last 4 or 5 years >> 2) Easily avoided with a "rebuild initramfs" notice during upgrade > > Take out that word "Easily", it doesn't belong there. > > What is the trigger condition that causes the message to be emitted? > > Will it be in each ebuild whose files might end up in an intramfs? > Expect much bitching and refusing from the devs who will have to > maintain that, so not gonna fly. > > Will it be at the tail end of all emerge actions? Ain't gonna fly either > as that is completely not a portage function. The PM installs and > updates packages, it does not check what you then do with the results. > And portage doesn't really know if you a) have an initramfs, b) where it > is, c) what you want in it (as opposed to what you have in it) > > Will it be a reminder after installing kernel sources? Changed sources > are not the cause of the isolated problems being mentioned here. Changed > userland is. > > Face it. If you want to use an initramf, IT IS THE USERS JOB to keep it > working as he wants it to work. It's a somewhat similar problem to out > of tree modules and keeping them installed and in sync - portage makes > zero effort to help with that one too.
True, but with the scripts that are floating in this thread, a usable solution can be build. Only need to finalize that into a generic option and document it in the wiki. Preferably as a "post-emerge" command. -- Joost
