I was referring to the difference between the two services (one provided by kernel-alive, and other provided by kernel-modules-hook).
I added an extra update to my post.
EDIT: To be more clear, both services are triggered. One of them uses rsync to copy stuff into the .old folder, while the other treats .old as a file.
That cannot be acceptable as two “non-conflicting” packages in the official repositories.
Copy that. Yes, I think we’ve found a bug. And unless I’m mistaken, the service files under /etc would normally simply be symlinks to the actual files under /usr. So there’s a discrepancy there as well. 
Maybe this is a case of miscommunication between Arch and Manjaro?
kernel-modules-hook used to be an exclusive AUR package, which was promoted (by Arch) to their official repositories.
kernel-alive is a Manjaro-exclusive package.
And thus, you have two conflicting packages that reside in the official Manjaro repositories.
To make matters worse, neither is defined to “conflict” with the other, and thus your package manager will not stop you nor warn you.
Well obviously one should not install both. Even so if kernel-alive is pre-installed in some cases already (full isos)
1.) Like @andreas85 , you might not know one is installed (let alone exists) as was the case of it being pre-installed with the ISO.
2.) You don’t shift the burden to the user to research the source code / PKGBUILD of every package they wish to install. These packaging issues are the responsibility of the package maintainers; not the end-users.
conflicts= and provides= are defined in the PKGBUILD.
Not anymore. It’s now removed from all ISO profiles.
Well, I have pinged @Ste74 to come and look at this thread; he’s the package maintainer of kernel-alive. 
Quick fix would be to define,
conflicts=kernel-modules-hook
Longterm fix would be what you described about the service/hook writing inside of /usr/.
Maybe instead of rsync’ing to (For the other package that is, but it’s a moot point if /usr/lib/modules/.old/, it can rather use /var/linux-alive/.old/ as the folder? kernel-alive works without issue, and rather re-locates the hidden .old file to /etc/ or elsewhere.)
Done. 
Well I remember kernel-modules-hook was in the AUR too, so it must have slipped Manjaro, they should decide which one to keep, true.
I’m not sure if such a drastic reaction was needed without reading what @Ste74 had to say first, it’s not like the forum was flooded by angry users with a broken system 
it’s one report and not clear enough how to reproduce.
All those years I had no problem with it for example.
Not in the slightest. There have been issues with it in the past reported, I’ve had issues with it and I removed it long ago.
Phil and I agreed to move it to community. Stefano has not been around much, FYI.
Can they? I’m not sure how Manjaro deals with Arch’s “Community” repo, in which many of those packages were promoted from the AUR previously. I assumed that Manjaro simply mirrors Arch’s Community repo.
Indeed. However, we can blacklist packages if necessary. In this case, there’s no reason to. The conflict I just added is enough.
I’m so disappointed. I really wanted a reason to write someone a mean-spirited nasty letter, forging @Aragorn’s signature. 
It’s not fair…
Well ok, but if we look at it now from the new / inexperienced users perspective, them losing the prompt to reboot their system can lead to much much more complaints about a non-working system 
. At least that should be mentioned somewhere imo, though one could argument new users would use the Pamac Manager .
Also it’s a bit sad seeing features that many were excited for New Manjaro function : kernel-alive - Manjaro Development - Manjaro Linux Forum in the past being axed (like also the linux-latest/lts metapackages etc) but OK I can be pragmatic, since I can’t code to help.
It’s not “axed”, it’s now just optional. Most users don’t even know it’s there, so it could actually be counterproductive for troubleshooting.
As far as the prompt, maybe we could include a needrestart hook instead like some other distros. It also prompts to restart services as well.
I’m trying to follow this thread after receiving the kernel-alive 0.5-2 update notice (core in my install ISO a few months ago) in pamac (curious what it was)… and am inclined to follow this advice…
Which I feel was also seconded…
However, I’m still wondering 2 things:
kernel-alive and kernel-modules-hook installed (the later not installed on my system) simutaneously… and adding the conflict in today’s update is a step towards removing that scenario?kernel-alive package, be to reboot after kernel updates; like I’m already doing? Or would I even experience any changes at all?You can safely remove the packages
sudo pacman -Rns kernel-alive kernel-modules-hook
The packages was created so a functional kernel was available even after syncing a new kernel package.
The reboot was often postponed for days and users forgot they had updated and suddenly the system malfunctions - which in turn created the idea of this set of packages.
I have never used the package and the editions I have maintained does not include this package and on occasion I have recommended to uninstall the packages.
If you want to see the original issue, see:
but it is a lot of reading / analysing
I only could follow these steps because i had btrfs-snapshots from before, within, after the update and from after the next 2 boots.
If someone does not have btrfs, or does not have snapper, or does not look into the snapshots he will only see the vanished modules.
this kind of bug is what I hate most … only some users are affected and it is not so easily reproducible to be able to understand what is wrong … I quickly read the whole post … even for me it is not reproducible: since when I made the package I use it and I never found myself unable to start the system … a week ago I switched to btfrs from ext4 who knows … I created it or at least I looked for a way to prevent that annoyance that occurs when you have a pendrive you are using and you need and updating you are unable to use it or it disappears and you have to restart …