| View previous topic :: View next topic |
| Author |
Message |
yzg
Guru
Joined: 18 Jun 2005
Posts: 499
|
 Posted: Sat Dec 30, 2017 2:40 am Post subject: why emerge --depclean un-emerges the current kernel |
 |
|
When a new kernel is released, running "emerge --depclean" will un-emerge the current kernel. If you are using nvidia-drivers, you could be waiting for weeks and several kernel release until the drivers support the newer kernel versions. In addition Gentoo usually removes the kernel ebuilds from portage to "force" people to upgrade to the new kernels.
In most cases, you end with a system where you cannot re-compile the old kernel, cannot re-emerge the old kernel, or compile the new kernel because of the nvidia-drivers.
I think, at least, " emerge --depclean" should not un-emerge the current kernel. We had discussions before on making the dependency between nvidia-drivers and kernel explicit but it went nowhere. |
|
| Back to top |
|
 |
asturm
Developer
Joined: 05 Apr 2007
Posts: 9307
|
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Sat Dec 30, 2017 6:26 am Post subject: |
|
|
| A couple things to keep in mind, is that Nvidia is well known to be slow to officially support the new kernel versions. This does not always mean that the nvidia-drivers doesn't work on newer versions of the kernel anyways. I know for a while, I was frequently using nvidia-drivers on newer kernel versions than they officially support and only had an issue once and a while. Even then, you can usually find a patch from the nvidia devs fairly regularly for newer versions of the kernel long before that version of the kernel is supported. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Dec 30, 2017 8:07 am Post subject: |
|
|
You're real issue there is how you handle your kernel.
- i won't expand on this again, but depclean is a space recovery program, not at all a critical maintenance tool, it does a similar work as eclean, but for whatever reason, users don't run eclean every 2s like mad, but they do with depclean.
- because you have add in your world file "gentoo-sources", it mean to portage "ok i want latest gentoo-sources, and this ONLY", and if any new gentoo-sources version is emerge, the previous installed versions are now all candidates to be depclean.
You have two ways to tell portage what you really want there:
* Either by adding in world the kernel you wish, be specific: if you have gentoo-sources-4.4.78 in world, gentoo will never install any new version, and depclean will always keep gentoo-sources-4.4.78 install. You can also have portage install latest gentoo-sources AND still protect gentoo-sources-4.4.78 from depclean, how (if you get it now): by having "gentoo-sources" and "gentoo-sources-4.4.78" in world ; "gentoo-sources" will trigger upgrade and installation of latest version, while "gentoo-sources-4.4.78" will protect this version from depclean.
* You could also just have "gentoo-sources" in your world file, but mask all versions higher than the one you want use, this way, you'll stuck latest version to be the wanted one, and depclean will never remove it as long as it remain latest version (so until you higher the mask and a newer kernel is emerge). |
|
| Back to top |
|
|
yzg
Guru
Joined: 18 Jun 2005
Posts: 499
|
| Posted: Sat Dec 30, 2017 12:36 pm Post subject: |
|
|
Guys, please do not be defensive.
I know how "emerge --depclean" works and how to work around it.
My question is simple: does it make sense for "emerge --depclean" to un-emerge the current kernel? |
|
| Back to top |
|
|
Section_8
l33t
Joined: 22 May 2004
Posts: 627
|
| Posted: Sat Dec 30, 2017 4:02 pm Post subject: |
|
|
| I saw the same thing with gentoo-sources-4.14.8-r1. If I understand asturm's post correctly, the problem is that 4.14.8-r1 was stabilized earlier and I installed it on Dec 23. Later, it was found to have bugs and so it was keyworded. Now, portage wants to unmerge it from a stable system. If you want to stay with it, just keyword that version. |
|
| Back to top |
|
|
yzg
Guru
Joined: 18 Jun 2005
Posts: 499
|
| Posted: Mon Jan 01, 2018 10:01 am Post subject: |
|
|
@krinn after you run "emerge -auvDN", you get this message:
* After world updates, it is important to remove obsolete packages with
* emerge --depclean. Refer to `man emerge` for more information.
So it is recommended and not because users are mad as you said.
As far as I know, sys-kernel/gentoo-sources is the only package where emerge does not do the real installation. Installation happens when you "manually" compile and install the kernel.
So the current kernel is the installed version of sys-kernel/gentoo-sources.
"emerge --depclean" does not remove important installed system packages but it does not follow this rule with. sys-kernel/gentoo-sources. It is a bug or undesirable feature  . |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9307
|
| Posted: Mon Jan 01, 2018 10:04 am Post subject: |
|
|
| No, it works as expected. Removing the sources does not break your already built kernel image and modules at all. If it is cleaned up it simply means a newer stable version is available, just as with any other package. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jan 01, 2018 11:37 am Post subject: |
|
|
| yzg wrote: | @krinn after you run "emerge -auvDN", you get this message:
* After world updates, it is important to remove obsolete packages with
* emerge --depclean. Refer to `man emerge` for more information.
So it is recommended and not because users are mad as you said. |
It is recommanded to "man emerge" about it, go man emerge and read about it, and you will see the warning : Always study the list of packages to be cleaned for any obvious mistakes.
The problem with this message is that experience users don't need it, and inexperience users that need that message the most, will not follow the "man emerge" advise.
In my opinion, this message should not exist, it instruct user to use a dangerous tool, and not emphasis enough that user need to read the manual about it prior using it.
| yzg wrote: | | "emerge --depclean" does not remove important installed system packages |
No, you are wrong ; there's no concept of "important" or "running".
And so depclean will happily remove important packages ; as depclean only care about packages in world (as system is in world, system too so).
The first filter is: is it in world or not : If it's not in world, it's a possible candidate for cleaning, the critical or important state of the package is not the question, the only question is : is it in world or not.
The second filter is: do someone use that version or not. And "someone" is not user, it's another package ; so do any package use it or not.
And you can browse the forum to see depclean (well, in real USERS!) failure : from memory, it goes to nano getting off, to gcc or libmpfr, or openrc ; and kernel sources removed is a classical case.
What you don't get with the kernel there, is that for depclean : you have in your world file "gentoo-sources", with no version, so you are saying "i want gentoo sources latest version".
If you use gentoo-sources-1 to boot, depclean don't care, as soon as gentoo-sources-2 is install, gentoo-sources-1 is useless for depclean.
And the logic is roughly that:
* is gentoo-sources in world
-> yes, i will keep it
* is gentoo-sources-2 in world
-> no, i could remove it
-> is it use by someone: gentoo-sources-2 is use by gentoo-sources -> i'll keep it
* is gentoo-sources-1 in world
-> no, i could remove it
-> is it use by someone: gentoo-sources-1 is not use by anyone (oh you use it to boot, but again "someone" is a package, not YOU" : CLEAN!
That's why you can protect gentoo-sources-1 by either telling "latest of gentoo-sources could only be gentoo-sources-1" (protect by mask) or "gentoo-sources-1 should be kept" (by adding gentoo-sources-1 in world).
And it will goes the same for any packages: you are running apache1, but apache2 version is emerge: portage will remove apache1 and don't gives a fuck if your server is using apache1, you have add "apache" in world and have let portage install apache2, so apache2 is the protect package there.
And this is why you get answer "it is expected", there is no bug there. |
|
| Back to top |
|
|
fe00
n00b
Joined: 19 Dec 2016
Posts: 7
|
| Posted: Tue Jan 02, 2018 8:02 am Post subject: |
|
|
| asturm wrote: | | No, it works as expected. Removing the sources does not break your already built kernel image and modules at all. If it is cleaned up it simply means a newer stable version is available, just as with any other package. |
Yet it breaks the system: i.e. just try to update "sys-fs/zfs-kmod" which needs the kernel sources. |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9614
Location: beyond the rim
|
| Posted: Tue Jan 02, 2018 9:07 am Post subject: |
|
|
| yzg wrote: | | My question is simple: does it make sense for "emerge --depclean" to un-emerge the current kernel? |
This question is a lot more complex than it seems (I recall having this discussion many years ago already).
First you need to define exactly what "current kernel" refers to. "So the current kernel is the installed version of sys-kernel/gentoo-sources." is way too vague as you can have many versions of different kernel sources installed at the same time. Basically there are two (three) variants to define "current kernel source package" (just to be clear that we're talking about the sources, not the binary image): Either by following the /usr/src/linux symlink, or by locating the sources that were used to build the currently running kernel image (or alternatively the image that would be loaded on next boot). However none of these variants fit very well into the dependency scheme used by portage. Basically you'd have to create a virtual package "sys-kernel/current-sources" inside portage that contains a dynamic dependency on the "current kernel source package" as defined above. That wouldn't be a big deal, except that dynamic dependencies don't work well with the metadata variable caching of portage, so it'd require special casing in many places. And special cases are generally the primary cause of problems.
TL;DR: The actual version of "current kernel sources" depends on the runtime state of the system, and such things aren't supported by the portage dependency mechanics.
| Quote: | | "emerge --depclean" does not remove important installed system packages but it does not follow this rule with. sys-kernel/gentoo-sources. It is a bug or undesirable feature . |
Well, for starters kernel sources are by definition not an important system package as they have zero impact on the running system, so excluding them from depclean is at most a convenience feature. You only need them when making system changes (changing kernel config or installing external modules). Removing them does not break your current system configuration, worst case it breaks the build process of other packages. That puts them at most in the same category as build tools like automake or autoconf. However those don't have the issue of the indirection layer between sources and binary images that the kernel has.
| Quote: | | Yet it breaks the system: i.e. just try to update "sys-fs/zfs-kmod" which needs the kernel sources. |
Breaking a package build is a completely different thing than breaking the system. |
|
| Back to top |
|
|
fe00
n00b
Joined: 19 Dec 2016
Posts: 7
|
| Posted: Tue Jan 02, 2018 9:43 am Post subject: |
|
|
| Quote: | Yet it breaks the system: i.e. just try to update "sys-fs/zfs-kmod" which needs the kernel sources.
| Quote: | | Breaking a package build is a completely different thing than breaking the system. |
|
No, in case of ZFS: you build + install your new kernel, remove the old one by sources, *and cannot* upgrade ZFS filesystem anymore. So the system is stuck in software upgrades. Thats a broken system to me. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 02, 2018 11:12 am Post subject: |
|
|
| fe00 wrote: | | Quote: | Yet it breaks the system: i.e. just try to update "sys-fs/zfs-kmod" which needs the kernel sources.
| Quote: | | Breaking a package build is a completely different thing than breaking the system. |
|
No, in case of ZFS: you build + install your new kernel, remove the old one by sources, *and cannot* upgrade ZFS filesystem anymore. So the system is stuck in software upgrades. Thats a broken system to me. |
Sorry, again no, your current zfs version is not broken and still running.
All packages that depends on kernel source will fail when kernel sources are gone, it's not new, nvidia-drivers is typical example (as certainly more common case).
But it doesn't mean your nvidia drivers are broken, and your system is running fine.
I don't know any packages that use kernel sources as run dependency. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2056
Location: United Kingdom
|
| Posted: Tue Jan 02, 2018 12:16 pm Post subject: |
|
|
As already pointed out, 'emerge --depclean' does not have a bug w.r.t. the kernel sources package; it behaves consistently for all packages and, as expected, will remove older gentoo-sources irrespective of the current kernel image. However, I have to admit it is a nuisance to discover you forgot to add gentoo-sources-123 to your world file and 'emerge --depclean' has therefore (correctly) un-merged it after 'emerge world' installed gentoo-sources-456. If, coincidentally, gentoo-sources-123 is no longer in the Portage tree you are left high and dry: you have a kernel image built from gentoo-sources-123 but no way of rebuilding that image. I've been in that situation myself on one occasion, and I had to search the Web to find the relevant Gentoo source code files. I suppose one way to protect the user against her/himself would be to modify the gentoo-sources ebuild so that it adds an entry for the merged gentoo-sources version to the world file in addition to the entry for gentoo-sources without a version number, and has an elog or ewarn message telling the user to remove the version-specific entry from the world file if (s)he wants to get rid of that specific version. It's a bit of a kludge, but would prevent inadvertent removal of a specific version of gentoo-sources.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10657
Location: Somewhere over Atlanta, Georgia
|
| Posted: Tue Jan 02, 2018 12:31 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | ... I suppose one way to protect the user against her/himself would be to modify the gentoo-sources ebuild so that it adds an entry for the merged gentoo-sources version to the world file in addition to the entry for gentoo-sources without a version number, ... |
You have a point but personally I dislike such special cases. You've also touched on the "standard" solution, which is to add your current working kernel to the world set: | Code: | | emerge --noreplace =gentoo-sources-<exact-version> |
with the obvious substitution.
Since this comes up from time to time, it's possible that this should get a brief mention in the Handbook.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
joanandk
Apprentice
Joined: 12 Feb 2017
Posts: 169
|
| Posted: Tue Jan 02, 2018 12:45 pm Post subject: |
|
|
| yzg wrote: | | My question is simple: does it make sense for "emerge --depclean" to un-emerge the current kernel? |
I have been using depclean for years and had no problems with the tool. I always use | Code: | | emerge -pv --depclean |
to check if there are packages getting uninstalled I still need.
If one does not f**k the world-file or emerge, everything works fine. I have once tortured an installation to the point where the system did break.
I must say, I am sort of happy that Kernel 4.9.72 was marked stable, some third-party drivers (digital devices dvb-c and virtualbox) were not yet available/stable for 4.12 and 4.14.
BR |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 02, 2018 12:56 pm Post subject: |
|
|
| John R. Graham wrote: | | Since this comes up from time to time, it's possible that this should get a brief mention in the Handbook.- John |
Or as elog, but i disagree, you just cannot tell user to add a kernel to its world file without telling him howto remove it after, and howto handle worldfile. That's the problem introduce by "use --depclean, read the man about it", users are not reading the manual but do take it as "i must run depclean".
The real issue is that emerge is hinting badly user to use -depclean ; this should be removed and user will stop using depclean (yeah, like mad).
And if anyone disagree, he should then mention "WHY" (any real example) using --depclean is vital and must be run.
Because there's only one reason to force user do depclean : making him removing package that aren't use or upgrade anymore by portage because it have a security issue. And he should then tell why that package has not been mask or removed (which is something glsa-check when mask for security, and portage when ebuild is not in the tree will take care to warn user about!)
But yes, maybe i'm not thinking about another use case where a user not using depclean is doing bad ; and maybe i'm just a lucky user then.
And to get clearer: keeping an old package (specially a lib) could do issue for user manually building a package, as it could wrongly link against it, but that's not a portage issue, it's a user issue to take care of package built out of the tree.
Or: in the tree package that would also do that ; but that's gentoo dev issue ; either the ebuild is wrongly made and miss that dependency (because if old package is a dep of the package, portage will then restart upgrade it...) or the build system is bad, but again, the gentoo dev allow the broken built system to escape the sandbox and use random libs it find in user system.
So i need an example of why keeping an old program or libs in a gentoo system would affect portage badly.
If none exists, it would mean like i keep saying (and many disagree with me with no real example) that --depclean is just a space saver tool, and nothing more. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9307
|
| Posted: Tue Jan 02, 2018 1:16 pm Post subject: |
|
|
| krinn wrote: | | he should then mention "WHY" (any real example) using --depclean is vital and must be run. |
If you don't run --depclean, in the long run you will be greeted with blockers due to orphaned packages like mad. So in the end it is a trade-off; do we want to discuss endlessly about the purpose and importance of kernel sources, or do we want to marvel at even more useless blocker bugs. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 02, 2018 1:45 pm Post subject: |
|
|
| asturm wrote: | | krinn wrote: | | he should then mention "WHY" (any real example) using --depclean is vital and must be run. |
If you don't run --depclean, in the long run you will be greeted with blockers due to orphaned packages like mad. So in the end it is a trade-off; do we want to discuss endlessly about the purpose and importance of kernel sources, or do we want to marvel at even more useless blocker bugs. |
Yeah i wish keep discussing about it : first because as user point out, --depclean is tell to user, and it's because user use that "recommendation that doesn't make any sense" that users keep getting kernel-sources remove without knowing what is going on.
I'm glad you provide an example, alas, that's a bad one: you have no more resolution trouble using a "dead/useless" package, because that package is not in world, it will never affect any resolution ; and it will "nearly" (see below) never increase any blockers.
For portage, as long as you don't specify it, that package doesn't exists.
If you have package_a that is not use by anyone, portage will never resolve anything for package_a as long as you don't use "emerge package_a" ; it is not in system, and not in world (that's why package_a is useless), and portage will never see it in any graph resolution from world or system, and even from any other package (else it would mean it's a dep and it's no more a useless package).
If package_b is not using package_a, but do seek package_a (because it cannot be install with package_a), you'll have a blocker (but a soft one), as portage see package_b and package_a cannot be install, but package_a is useless and portage will tag it "b" (and not "B") : no issue again. So yes, this special case (and i must say rare case), will increase blockers, but nothing for user, a soft block portage will gently handle itself.
If package_a is an orphan package : portage will tell you about (something like, no ebuild for package_a exists).
If you really want help "dumb" user, you can then, this time, with the "no ebuild for package_a" message, hint user to emerge -c package_a.
However, except user that may be bored to see "no ebuild for package_a" again and again, i see no other issue for portage except this message. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2056
Location: United Kingdom
|
| Posted: Tue Jan 02, 2018 2:11 pm Post subject: |
|
|
I think the 'emerge --depclean' message at the end of an 'emerge world' is fine, and useful. It just reminds me to do it, that's all.
Personally, once I had learned how 'emerge --depclean' worked w.r.t. gentoo-sources, I didn't need any special measures; I just do what needs to be done to either keep or discard the particular version of gentoo-sources. However, I can see that beginners could fall foul of this functionality (once bitten, twice shy?) and so, at the very least, it could be worth adding an elog or ewarn message to the end of the ebuild for gentoo-sources to remind the user to add the specific version of gentoos-sources to the world file if desired, and to remove it later if desired. Something along the following lines, for example:
| Code: | pkg_postinst() {
elog "By default, emerge --depclean will remove this version of gentoo-sources if a later version is installed."
elog "Therefore, if you wish to preserve this version of gentoo-sources add it to the world set:"
elog "emerge --noreplace =gentoo-sources-<this-version>"
elog "To reverse the above and allow emerge --depclean to remove this version if a later version is installed,"
elog "remove it from the world set:"
elog "emerge --deselect =gentoo-sources-<this-version>"
elog "See emerge(1) manual page."
}
|
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9307
|
| Posted: Tue Jan 02, 2018 2:15 pm Post subject: |
|
|
| krinn wrote: | | I'm glad you provide an example, alas, that's a bad one: you have no more resolution trouble using a "dead/useless" package, because that package is not in world, it will never affect any resolution ; and it will "nearly" (see below) never increase any blockers. |
No, that's not true at all. Probably half of all all slot conflicts is coming from installed orphans that were built depending on an old (sub-)slot and are never slated for rebuild again, because they are not part of the depgraph. Until the slot is bumped and rdeps need rebuild - boom. |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10657
Location: Somewhere over Atlanta, Georgia
|
| Posted: Tue Jan 02, 2018 3:49 pm Post subject: |
|
|
| krinn wrote: | | John R. Graham wrote: | | Since this comes up from time to time, it's possible that this should get a brief mention in the Handbook.- John |
Or as elog, but i disagree, you just cannot tell user to add a kernel to its world file without telling him howto remove it after, and howto handle worldfile. |
Well what I meant (but didn't say) was that there could be a new "Kernel Source Management Best Practices" section under "Working with Gentoo", perhaps. It needn't be too long, but it's probably more than a mention. 
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2056
Location: United Kingdom
|
| Posted: Tue Jan 02, 2018 5:06 pm Post subject: |
|
|
| John R. Graham wrote: | | krinn wrote: | | John R. Graham wrote: | | Since this comes up from time to time, it's possible that this should get a brief mention in the Handbook.- John |
Or as elog, but i disagree, you just cannot tell user to add a kernel to its world file without telling him howto remove it after, and howto handle worldfile. |
Well what I meant (but didn't say) was that there could be a new "Kernel Source Management Best Practices" section under "Working with Gentoo", perhaps. It needn't be too long, but it's probably more than a mention.
- John |
Measures need not be mutually exclusive: there could be additional documentation as well as an elog message. And the example elog message I gave in my previous post explains to the user both how to add and how to remove the specific version of gentoo-sources from the world set.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 02, 2018 6:52 pm Post subject: |
|
|
| asturm wrote: | | No, that's not true at all. Probably half of all all slot conflicts is coming from installed orphans that were built depending on an old (sub-)slot and are never slated for rebuild again, because they are not part of the depgraph. Until the slot is bumped and rdeps need rebuild - boom. |
I don't see how a pck:1 unused would conflict with a pck:7 slot myself.
And if you were thinking about some pck-1.0:1 and pck-1.1:1, i have just never seen portage complain for that, this, as long as nobody use pck-1.0 (which is a need to have pck-1.0 mark as "useless"). And if anyone is trying to use some pck-1.1 version, it mean it's no more useless, and portage will have 0 (yeah i'm sure 0) trouble updating pck-1.0:1 to pck-1.1:1 because nobody use pck-1.0.
For me most common case of slots conflict (i wouldn't put like you a "half" of them) are coming specially because someone is using the slot.
And the conflict is because of that: pck-1.0:1 is use by pck-b and trying to install pck-1.1:1 conflict if pck-b is mark to work only with pck-1.0 (so same slot, but pck-1.0 must remain in that slot to agree with pck-b that do use it).
but maybe i'm not getting good what you're speaking about, if you have a real example or a deeper explain of such scenario. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9307
|
| Posted: Tue Jan 02, 2018 7:00 pm Post subject: |
|
|
Emphasis on rdeps (reverse-dep) *depending* on slotted deps (libraries). Obviously I could have been clearer.
C is installed as :1/1.
A, registered in world or depended on by rdeps -> C:1=
B, not registered in world and no rdeps on it (maybe in the past some D depended on B but you unmerged that) -> C:1=
Somewhere along the way, B may be even dropped from tree.
Update C:1/2
- A, installed, is slated for rebuild by C:1/2 bump
- B, installed, not in world, no rdeps, is not considered for rebuild and continues to insist on :1/1
Portage is not able to resolve the conflict. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
