Let's assume we have an ebuild - app-text/greatstuff-0.5-r1 that is stable - app-text/greatstuff-0.7_beta2 that is masked ** --> emerge -av greatstuff would install version 0.5. --> ACCEPT_KEYWORDS=** emerge -av greatstuff would install version 0.7_beta2 OK, I want to use the 0.7_beta2 one and issue the second command in order to get it installed. Now the dev add 0.7_beta3. If I update world, the ebuild would not be updated due to being masked by missing keyword. I actually want portage to update to the 0.7_beta3 version because I once managed to have the 0.7_beta2 version installed in the same slot (that was masked) Did you get what I wanted to describe? emerge should, once a package in a slot is installed, updated the ** masked ebuilds as these were not masked. Reproducible: Always Actual Results: portage has no update Expected Results: portage has update on 0.7_beta3
To sum it all up in one sentence one could say: emerge should ignore an ebuild's "missing keyword" mask once the ebuild is installed.
(In reply to comment #0) > --> emerge -av greatstuff would install version 0.5. > --> ACCEPT_KEYWORDS=** emerge -av greatstuff would install version 0.7_beta2 This approach is somewhat messy for various reasons. For example, with ** you're probably going to pull in live -9999 ebuilds, which is probably not desirable for most people. As an alternative, I'd suggest the --autounmask option.
Could one implement that for ebuilds that do not depend on a cvs as git, svn, ... for fetching the source? That would cover the case for the live-ebuilds.
(In reply to comment #3) > Could one implement that for ebuilds that do not depend on a cvs as git, svn, > ... for fetching the source? That would cover the case for the live-ebuilds. It's possible to use a blacklist of inherited eclasses, but not really optimal. It would be better if we implemented something like PROPERTIES=live, as suggested here: http://archives.gentoo.org/gentoo-dev/msg_64b83155637bcad67478e2d2af276780.xml
There are other problems: You wont notice if a package gets masked for removal or if a newly added version gets masked because it has serious bugs. I think the main problem here is that portage allows specifying ACCEPT_KEYWORDS and other stuff on the command line. That's just bad practice. Config files are there for a reason.
(In reply to comment #5) > There are other problems: You wont notice if a package gets masked for removal > or if a newly added version gets masked because it has serious bugs. > > I think the main problem here is that portage allows specifying ACCEPT_KEYWORDS > and other stuff on the command line. That's just bad practice. Config files are > there for a reason. > OK, ste 1: DO NOT REMOVE THAT! My whole life depends on it. OK, partially. :)
I have the following script laying around to show me what live-ebuilds I have installed: #!/usr/bin/python import portage db = portage.db["/"]["vartree"].dbapi vcs_eclasses = set(["cvs", "git", "subversion", "bzr", "monotone"]) for cpv in db.cpv_all(): try: eclasses = db.aux_get(cpv, ["INHERITED"])[0].split() except KeyError: pass if vcs_eclasses.intersection(eclasses): print cpv
(In reply to comment #5) > There are other problems: You wont notice if a package gets masked for removal > or if a newly added version gets masked because it has serious bugs. > To come back to the removal thing: When the ebuild actually is removed, it resides on the machine anyways wether it was masked for removal or not. I do an "eix-test-obsolete detail" from time to time to see what needs to be done on the machines.
Any news on this, Zac? :)
Close as WONTFIX wrt comment 5? :)
(In reply to comment #7) > I have the following script laying around to show me what live-ebuilds I have > installed: To do this cleanly, you really need more metadata in the ebuilds, which would depend on bug 182028 or the PROPERTIES=live thing I mentioned earlier. (In reply to comment #10) > Close as WONTFIX wrt comment 5? :) Yeah, for now emerge --autounmask is the only thing close that I can recommend.
