Scenario: - I build up a whole system, with a lot of packages, E.G.: KDE - I don't update the system for a few months. Please note I'm a real user, I don't just use Gentoo to see if it works and take pride as I'm able to compile it. - I run an emerge --sync. Lots of new ebuilds come, lots are deleted. - I try to update maybe a single package, something simple, E.G.: Dolphin for KDE. Outcome: I have to keyword about 30 other KDE packages, in various rounds and then I still can't update it because some old packages which needed to be rebuilt... have been deleted in the last emerge --sync !!! The slot conflict(s) shown above involve package(s) which may need to !!! be rebuilt in order to solve the conflict(s). However, the following !!! package(s) cannot be rebuilt for the reason(s) shown: (kde-plasma/kwin-5.14.5:5/5::gentoo, installed): ebuild is masked or unavailable (kde-plasma/plasma-integration-5.14.5:5/5::gentoo, installed): ebuild is masked or unavailable (kde-frameworks/qqc2-desktop-style-5.57.0:5/5.57::gentoo, installed): ebuild is masked or unavailable This is happening just too often (a polite way to say every time) and needs fixing, e.g., by not removing ebuilds from portage too early, or have a standard setting to preserve them for as long as they are referenced by world, or other installed ebuilds.
You are welcome to seek help with aspects of rolling release maintenance in the forums or in IRC #gentoo.
I'm not seeking help. I'm reporting an issue
Expected outcome, either of: 1 - older ebuilds should not be deleted by Gentoo maintainers from the portage tree (I understand probably unfeasible) 2 - Portage should be able to fetch those missing ebuilds from a dedicated old-ebuilds repository, where no ebuild gets ever deleted, so it can resolve the dependency tree, rebuild the packages that need rebuilding. All this without the user having to manually mask/unmask/delete packages, manually restore old ebuilds, etc.
(In reply to skaumo from comment #0) > - I don't update the system for a few months. Good luck with that.
> Good luck with that. Ah, the joke?? Yeah, very funny. If a rebuild of and EXISTING, INSTALLED package is triggered by an update of a reverse dependency, the corresponding ebuilds MUST be retained so long as the package is installed. No way WONTFIX here. The current one is a completely nonsense behaviour and defeats one of the greatest features of Portage. Not sure what's wrong expecting to retain the source code to reinstall something that's already installed??? E.G.: Do you delete /usr/src/linux, as well, every time you compile your kernel? Do you delete all your sources from /usr/portage/distfiles every time you emerge them? So, why such a rush deleting ebuilds, then? If something is installed, it means you are using it and you just need its source AND ebuilds, so don't delete them.
(In reply to skaumo from comment #5) > > Good luck with that. > > > Ah, the joke?? > Yeah, very funny. No joke. In line with the advice from comment #1, I was wishing you good luck solving your local problem, which is caused by failing to or refusing to update your entire set of installed packages, and instead wanting to update just a single package, as you outlined in comment #0, viz.: "I try to update maybe a single package, something simple, E.G.: Dolphin for KDE.". Updating just a few packages and not the entire installed base has never been supported. This is especially true for packages like kde-apps/dolphin as that depends on many other (KDE) packages that need to be kept in sync. The advice you would have gotten from our normal support avenues, such IRC and relevant mailing lists, would probably have mostly involved updating the entire set as opposed to a single package. This bug report was initially marked INVALID because you brought your support issue to the wrong place: there is no bug here because you cannot update just a single package when that would violate lots of dependencies between (other, seemingly unrelated) packages. I am aware that this could have been explained better. > If a rebuild of and EXISTING, INSTALLED package is triggered by an update of > a reverse dependency, the corresponding ebuilds MUST be retained so long as > the package is installed. That would superficially appear to be the case, but there is a valid upgrade path for those dependency packages, so keeping obsolete ebuilds around for people who do not regularly upgrade (and want to update just a single package and not the set) is not the solution, was never a viable solution to begin with, and is not the correct conclusion to the issue you are facing, which is not a bug.
(In reply to Jeroen Roovers from comment #6) > That would superficially appear to be the case, but there is a valid upgrade > path for those dependency packages, so keeping obsolete ebuilds around for > people who do not regularly upgrade (and want to update just a single > package and not the set) is not the solution, was never a viable solution to > begin with, and is not the correct conclusion to the issue you are facing, > which is not a bug. > Valid upgrade path Valid depends on the case and "upgrade path" is another word for "workaround". You only need workarounds when you have bugs. So, let's rephrase and re-summarise the problem, because it doesn't only manifest itself in the aforementioned scenario, and does not only apply when you don't update packages for a long time: 1) Someone in Gentoo decides to perform an apparently harmless patch update of "package1" (package1-r1 -> package1-r2) 2) Without thinking twice, the maintainer deletes the ebuild for package1-r1. 3) So, running an emaint sync just 10m later, we silently lose it. 4) Turns out the updated package1-r2 just fails on my system, so I can't update it. 5) Meantime, trying to install or upgrade package2 triggers a rebuild of package1, but since package1-r1 is lost and package1-r2 is broken, we are stuck. 6) Portage, during a sync, by deciding to remove the ebuild of an installed package, has lost the ability to bring the system back to a consistent state (hey, that's exactly the purpose of portage, isn't it?). It has cut its own legs then it figured out it can't walk and cries out. This really fits the definition of a bug. So, I didn't break portage, but it broke itself. There are workarounds? Maybe, but that's not the point. If it doesn't do what's supposed to do, then it's a bug. Ebuilds get fixed quickly? Not always (think ekiga, worldofpadman, just to mention a few, left broken for many, many months) By the way, Portage has already implemented some conceptually similar features in the past, like preserved libs (understand the reference?), so I really can't see any reason why this one should not be acknowledged and fixed.
It is a known problem, that updates can become difficult, if you do not update for a long time. KDE is a complicate candidate, because it ships many dependencies and can quickly become unclear. Any improvement is welcome and I agree, that we can call it a bug, if you can not update after 12 months. However this ticket will not lead to any improvement, because the bug tracker is not well suited for discussion and the problem is very complicate. I suggest that you discuss it on IRC. You can help by collecting new knowledge on your wiki page and we can update https://wiki.gentoo.org/wiki/Upgrading_Gentoo together. We should write down systematically the typical problems for a breakage. a) then we can elaborate a quick solution for the specific situation for the user b) if there is a solution in portage: open a ticket and describe the feature request precisely. c) we can also discuss, if specific problems can be solved by different workflows. But we cannot discuss this on bugzilla. I will close this ticket here, because the topic of the ticket is too broad. I hope you understand it and I ask everyone not to use the bug tracker for discussion or even snarky comments.
