| Summary: | missing /etc/portage/sets/world link breaks world file update | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | James C. Georgas <james.georgas> |
| Component: | New packages | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | sascha-gentoo-bugzilla |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
James C. Georgas
2005-02-01 16:54:57 UTC
Excuse me, that should have read:
/var/lib/portage/world
not:
/var/log/portage/world
ehm, which one is the symlink at which one is the real file? On my system, the real file is in /var/lib/portage and the (missing) symlink is in /etc/portage/sets Ok, I don't know what's going on, but it's working again. It doesn't seem to have anything to do with the /etc/portage/sets/world symlink. I set the permissions on /var/lib/portage/world to 777, and it started working. I removed the symlink and it kept on working. I then put the permissions back to 640, and it kept on working. ... I don't know what to say. It doesn't always add things to world. There is a scheme for what goes in. I know that it doesn't add dependencies to world unless you explicitly name them, but it should always put the packages you name in. Otherwise, doing a --depclean would completely mess up your system. Anyway, I tested it by adding and removing one particular package (stellarium), and it works now. I may have misread the original permissions on the world file. It was working in the past, and then it wasn't, and now it is again. The only thing that changed that I can see was the directory path for the world file, and maybe some owner/permission related stuff. I isolated the problem I had with the world file. It has nothing to do with the /etc/portage/sets/world symlink after all. If I emerge a new package with the -u option, it doesn't get added to the world file. That's it. I read the appropriate section in the man page, and it recommends that one only use -u with the world and system targets, to avoid updating dependencies of the specified package. However, I pass the -u option on the command line when installing a new package specifically to cause an update of the dependencies. That's what I want to happen. This is a problem when you modify your USE variable. Then using emerge -uDN package_name may lead to recompilation of this package_name + installation of new packages (for instance, install mplayer. Then add matroska to USE. emerge -uDN mplayer will lead to [U] mplayer but also [N] matroska). The new packages are not added to world. -u should add packages to the world file anyway, if they are installed as [N]. Well, I would not want dependencies of the package I am trying to install to be added to the world file, since this would cause confusion later, when I read it and it contains a bunch of stuff that I didn't tell portage explicitly to install. Gnome is a good example, where all I want in the world file is "gnome" and not stuff like libbonobo, which is a dependency. Every package is "N" the first time it is installed, right? So, for Eric's USE flag example, I would not want matroska to be added to my world file. It is a dependency of mplayer now, even though it wasn't one before he changed his USE flags. The world file should only contain packages I typed on the command line, but it should contain all the packages I typed on the command line. So, to use Eric's example again, if I do not have mplayer installed and I type 'emerge mplayer', then mplayer gets added to the world file, but if I do not have mplayer installed and I type 'emerge -u mplayer', then mplayer does not get added to the world file. That's the bug I'm trying to illustrate here. /etc/portage/sets is not used at all at the moment. *** This bug has been marked as a duplicate of 48181 *** |
