Re: [gentoo-user] xorg.conf [SOLVED]
I have never seen a good reason why a package *shoulnt* be in the world file. Especially dependencies. I am continually getting surprised by emerge -s showing new versions of packages that emerge -u and sometimes emerge -uD do not see. Not good. depclean is unclean = system breaker. It has its uses, but when it goes wrong ... BillK On Thu, 2005-10-13 at 11:16 +0200, Holly Bostick wrote: > Jorge Almeida schreef: > > I don't do much emerge world, I usually just "-p"-it and then emerge > > each package, that's why I didn't think of that. > > That seems like a waste of effort -- and 'corrupts' your world file, as > well, since everything you emerge explicitly will be entered into your > world file, and that will then include dependencies, which should by > rights *not* be in your world file, nothing said about dependencies of > dependencies, also known as 'deep dependencies'. > > You're really making a mess doing that; you'll screw up emerge > --depclean, for one thing, since I have no idea what it would do if a > dependency of an uninstalled package in your world file (which would > normally make the package a valid target for depclean) is also in your > world file, given that dependencies are not meant to be in your world > file (thereby invalidating the now-useless package as a depclean target): > -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] xorg.conf [SOLVED]
Jorge Almeida schreef: > I don't do much emerge world, I usually just "-p"-it and then emerge > each package, that's why I didn't think of that. That seems like a waste of effort -- and 'corrupts' your world file, as well, since everything you emerge explicitly will be entered into your world file, and that will then include dependencies, which should by rights *not* be in your world file, nothing said about dependencies of dependencies, also known as 'deep dependencies'. You're really making a mess doing that; you'll screw up emerge --depclean, for one thing, since I have no idea what it would do if a dependency of an uninstalled package in your world file (which would normally make the package a valid target for depclean) is also in your world file, given that dependencies are not meant to be in your world file (thereby invalidating the now-useless package as a depclean target): man emerge --depclean Determines all packages installed on the system that have no explicit reason for being there. emerge generates a list of packages which it expects to be installed by checking the system package list and the world file. It then compares that list to the list of packages which are actually installed; the differences are listed as unnecessary packages and then unmerged after a short timeout. WARNING: Removing some packages may cause packages which link to the removed package to stop working and complain about missing libraries. Re-emerge the complaining package to fix this issue. Note that changes in USE flags can drastically affect the output of --depclean. But if a dependency of an uninstalled package is in your world file (which in your situation it could be), then it *does* have a reason for being there (because it's in the world file), so would not be cleaned, which is just not the way Portage is set up to work. You might consider changing -p to -a when doing an emerge world (--pretend to --ask), so that you can see what's being emerged and not have to go to all the effort of typing the emerge command again (or, heaven forfend, individual commands the way you do now) You might also consider adding -u (--update), -D (--deep), -t (--tree) and -v (--verbose) to 1) catch updated direct dependencies; 2) catch updated indirect (deep) dependencies, 3) see which packages are requiring that a dependency or deep dependency be updated; and 4) see what the USE flag status is for all requested-to-emerge packages. I don't offhand know how to 'fix' your world file, but I'm pretty sure that one of ecatmur's utilities, posted on the forums, is likely designed to solve this issue. I remember a thread called 'Clean out your World file'... can't find it, but there is this: Portage utilities not in Portage: http://forums.gentoo.org/viewtopic.php?t=67849 which ought to have something of use. Hope this helps, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] xorg.conf [SOLVED]
On Thu, 13 Oct 2005 08:48:27 +0100 (WEST), Jorge Almeida wrote: > > Glad that worked for you, but please now remember to add nvidia-kernel > > and nvidia-glx to /etc/portage/package.keywords as allowed to be ~x86, > > or else Portage will try to downgrade them the next time you do an > > emerge world-- ACCEPT_KEYWORDS on an emerge command line is only > > *temporary for that emerge*, and *is not remembered permanently by > > Portage*. > > > I don't know if it's a good idea, in this case. After all, the current > masked version will be unmasked one day, and I may not need always the > bleeding-edge version (I'd rather use stable things, if they do the > job). In this case, ~arch is not bleeding edge. The ebuild of the latest release version of the nVidia drivers is usually ~arch, even though the drivers themselves are tested. -- Neil Bothwick LISP: Lots of Infuriating & Silly Parentheses pgpDhMM9U1n8n.pgp Description: PGP signature
Re: [gentoo-user] xorg.conf [SOLVED]
On Thu, 13 Oct 2005, Holly Bostick wrote: > > The solution for your stated preference is to unmask the packages' > keyword in /etc/portage/package.keywords, and mask all versions of the > package above the one you have now, so that they do not appear if an > update occurs and you do not want to update to a further unstable version: > > #echo 'media-video/nvidia-kernel ~x86' >>/etc/portage/package.keywords > #echo 'media-video/nvidia-glx ~x86' >>/etc/portage/package.keywords > #echo '>media-video/nvidia-kernel-1.0.7676' >>/etc/portage/package.mask > #echo '>media-video/nvidia-glx-1.0.7676-r1' >>/etc/portage/package.mask > > You would of course have to keep an eye on the Portage tree so you would > know when to remove the masks and unmask entries, but you could get > through your daily life without having to re-emerge everything all the time. > OK, will do that. I don't do much emerge world, I usually just "-p"-it and then emerge each package, that's why I didn't think of that. Thank you (and to Christoph too). Jorge -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] xorg.conf [SOLVED]
Jorge Almeida schreef: > On Thu, 13 Oct 2005, Holly Bostick wrote: > > >> Jorge Almeida schreef: >> >>> It seems it's a known bug. I emerged nvidia-kernel and nvidia-glx >>> with ACCEPT_KEYWORDS="~x86" and it works now. >>> >> >> Glad that worked for you, but please now remember to add >> nvidia-kernel and nvidia-glx to /etc/portage/package.keywords as >> allowed to be ~x86, or else Portage will try to downgrade them the >> next time you do an emerge world-- ACCEPT_KEYWORDS on an emerge >> command line is only *temporary for that emerge*, and *is not >> remembered permanently by Portage*. >> > > I don't know if it's a good idea, in this case. After all, the > current masked version will be unmasked one day, and I may not need > always the bleeding-edge version (I'd rather use stable things, if > they do the job). But I always issue emerge -pv before emerging > anything, so a possible downgrade would be detected in advance. Yes, I understand you-- but what then are you going to do when the downgrade is detected? You won't have a choice but to downgrade; if you try masking packages lower than the current one, you'll get an error saying that all available packages are masked, and if you do downgrade, your X will be broken again until you re-emerge the unstable version with ACCEPT_KEYWORDS on the command line-- EVERY TIME you do an emerge (-whatever) world. Is that what you want? The solution for your stated preference is to unmask the packages' keyword in /etc/portage/package.keywords, and mask all versions of the package above the one you have now, so that they do not appear if an update occurs and you do not want to update to a further unstable version: #echo 'media-video/nvidia-kernel ~x86' >>/etc/portage/package.keywords #echo 'media-video/nvidia-glx ~x86' >>/etc/portage/package.keywords #echo '>media-video/nvidia-kernel-1.0.7676' >>/etc/portage/package.mask #echo '>media-video/nvidia-glx-1.0.7676-r1' >>/etc/portage/package.mask You would of course have to keep an eye on the Portage tree so you would know when to remove the masks and unmask entries, but you could get through your daily life without having to re-emerge everything all the time. Hope this helps, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] xorg.conf [SOLVED]
Jorge Almeida wrote: Glad that worked for you, but please now remember to add nvidia-kernel and nvidia-glx to /etc/portage/package.keywords as allowed to be ~x86, or else Portage will try to downgrade them the next time you do an emerge world-- ACCEPT_KEYWORDS on an emerge command line is only *temporary for that emerge*, and *is not remembered permanently by Portage*. I don't know if it's a good idea, in this case. After all, the current masked version will be unmasked one day, and I may not need always the bleeding-edge version (I'd rather use stable things, if they do the job). But I always issue emerge -pv before emerging anything, so a possible downgrade would be detected in advance. Won't happen if you unmask only the specific version you are using: # echo "=media-video/nvidia-kernel-1.0.7174 ~x86" >> /etc/portage/package.keywords Christoph -- echo mailto: NOSPAM !#$.'<*>'|sed 's. ..'|tr "<*> !#:2" [EMAIL PROTECTED] -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] xorg.conf [SOLVED]
On Thu, 13 Oct 2005, Holly Bostick wrote: > Jorge Almeida schreef: > > It seems it's a known bug. I emerged nvidia-kernel and nvidia-glx > > with ACCEPT_KEYWORDS="~x86" and it works now. > > > > Glad that worked for you, but please now remember to add nvidia-kernel > and nvidia-glx to /etc/portage/package.keywords as allowed to be ~x86, > or else Portage will try to downgrade them the next time you do an > emerge world-- ACCEPT_KEYWORDS on an emerge command line is only > *temporary for that emerge*, and *is not remembered permanently by Portage*. > I don't know if it's a good idea, in this case. After all, the current masked version will be unmasked one day, and I may not need always the bleeding-edge version (I'd rather use stable things, if they do the job). But I always issue emerge -pv before emerging anything, so a possible downgrade would be detected in advance. Jorge -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] xorg.conf [SOLVED]
Jorge Almeida schreef: > It seems it's a known bug. I emerged nvidia-kernel and nvidia-glx > with ACCEPT_KEYWORDS="~x86" and it works now. > Glad that worked for you, but please now remember to add nvidia-kernel and nvidia-glx to /etc/portage/package.keywords as allowed to be ~x86, or else Portage will try to downgrade them the next time you do an emerge world-- ACCEPT_KEYWORDS on an emerge command line is only *temporary for that emerge*, and *is not remembered permanently by Portage*. ACCEPT_KEYWORDS on an emerge command line is really a recipe for grief if you don't complete the operation by validating the ~arch keyword in some fashion (if you find you want to keep the package, which in this case you do). Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] xorg.conf [SOLVED]
It seems it's a known bug. I emerged nvidia-kernel and nvidia-glx with ACCEPT_KEYWORDS="~x86" and it works now. -- Jorge Almeida -- gentoo-user@gentoo.org mailing list
