This essentially reopens bug 35070, but I guessed enough time has passed that a new bug is called for. That one was marked as invalid. I urge reconsideration. My reason: emerging and old libc binary package was disallowed for a failed dependency on virtual glibc. Consider: 1) What are the chances I'm running portage without a working glibc? 2) What is the use of dependency checking at all if every binary emerge requires --nodeps? It may be that this is somehow a special case; I don't know enough about portage to determine that. But it sure strikes me as odd, not to mention frustrating. If libc is special and this does not occur that much in practice, perhaps there's a way to either alert the poor user, or make it *not* explicitly depend on glibc.
This bug looks invalid. Please provide a testcase.
Created attachment 89224 [details] output of emerge --info
(In reply to comment #1) > This bug looks invalid. Please provide a testcase. > I'm not sure what's required, but I've attached emerge --info, and quoted my original complaint on gentoo-user forum, under the thread "Use and removal of binary packages". Please not that I used the lowercase "k", which I had supposed meant to use both binary and portage packages. It then says there's no package for "glibc". That is just about astonishing. I couldn't get that far without a working glibc. So I submit that portage should be changed in one of these ways: 1) portage should lighten up and allow non-binary dependencies (I cannot see why not, particularly for the permissive -k). 2) notice packages that are in the profile and let the user rely on them at least 3) make a better diagnostic message that says it has no *binary* package for that dependency (which would help the user identify the real as opposed to the apparent problem). The current message complains about "ebuilds" which in fact it *does* have, not about *binary packages* which admittedly it does not. 4) confirm that the user desires to rely on particular non-binary ebuilds. Okay, with that said, here's what I was complaining about: > Okay, that helped. But not as much as I had hoped. > > Now I get: > > treat dev-libs # emerge -avk =glib-1.2.10-r5 > > > > These are the packages that would be merged, in order: > > > > Calculating dependencies - > > emerge: there are no ebuilds to satisfy "virtual/glibc". > > (dependency required by "dev-libs/glib-1.2.10-r5" [binary]) > > > > treat dev-libs # > So it sees that it has the glib package, but is still unwilling to emerge it > because of something else I need to do. But I don't know how to find > out what to do about this virtual. In /var/cache/edb/virtuals, I have > > virtual/glibc sys-libs/glibc > > > and I have 2.3.6-r3 installed: > > > sys-libs/glibc > > Available versions: [P]2.2.5-r10 [P]2.3.2-r12 2.3.3.20040420-r2 > ~2.3.4.20040619-r2 2.3.4.20040808-r1 2.3.4.20041102-r1 *2.3.4.20041102-r2 > ~2.3.4.20050125-r1 2.3.5 2.3.5-r1 2.3.5-r2 2.3.5-r3 *2.3.6 *2.3.6-r1 > ~2.3.6-r2 2.3.6-r3 ~2.3.6-r4 ~2.4-r1 ~2.4-r2 ~2.4-r3 > > Installed: 2.3.6-r3 > > Homepage: > http://www.gnu.org/software/libc/libc.html > > Description: GNU libc6 (also called glibc2) C library > > > >
(In reply to comment #0) > 1) What are the chances I'm running portage without a working glibc? > 2) What is the use of dependency checking at all if every binary > emerge requires --nodeps? If you want to ignore some deps but don't want to use --nodeps, your alternative is to use /etc/portage/profile/package.provided (documented in `man portage`).
(In reply to comment #3) > (In reply to comment #1) > > This bug looks invalid. Please provide a testcase. > > > > I'm not sure what's required, but I've attached emerge --info, and quoted > my original complaint on gentoo-user forum, under the thread > "Use and removal of binary packages". Please not that I used > the lowercase "k", which I had supposed meant to use both binary > and portage packages. It then says there's no package for "glibc". > That is just about astonishing. I couldn't get that far without > a working glibc. So I submit that portage should be changed in one > of these ways: -k works how you like, uses binary packages if they exist, otherwise uses source packages. > Okay, with that said, here's what I was complaining about: > > > > Okay, that helped. But not as much as I had hoped. > > > > Now I get: > > > treat dev-libs # emerge -avk =glib-1.2.10-r5 > > > > > > These are the packages that would be merged, in order: > > > > > > Calculating dependencies - > > > emerge: there are no ebuilds to satisfy "virtual/glibc". > > > (dependency required by "dev-libs/glib-1.2.10-r5" [binary]) This is a completely unrelated issue. If there was no binary package, portage would say so, ala: gentoo apache2 # emerge -K silo Calculating dependencies !!! There are no packages available to satisfy: "silo" !!! Either add a suitable binary package or compile from an ebuild.
