I have a world file which contains entries such as =app-office/openoffice-1.1.1 yet when I do an emerge -pv world portage wants to upgrade my openoffice installation. Portage used to successfully honor specific version specifications in the world file. It appears that this is broken. A search on the forums mentions that this is a common issue -- however I didn't find any other bugs filed with this specific description. Reproducible: Always Steps to Reproduce: 1. pin a version in the world file 2. use emerge -pv world to see that it is not getting honored Actual Results: emerge appears to ignore the version specification Expected Results: emerge should honor the version specification (it did in the past). I have seen this on two systems. They are both running sys-apps/portage-2.0.51.19. I know this used to work, but I don't have a clear idea which portage upgrade broke this functionality.
This isn't supported anymore since 2.0.50, use package.mask instead.
Marius, Thanks for the suggestion. So it looks in general like I can take any =category/package-version statement in my world file and simplify it to just category/package then add a corresponding >cateogory/package-version statement to the package.mask file in /etc/portage. However -- this means something a little different. In one case I was telling portage not to update a specific item. In the other case I am telling portage to consider anything newer than a specific version to be masked. I'm not just being nit-picky (I don't think I am anyway -- I guess I might just not understand something here) it seems like these two statements would have a different meaning with respect to slots. For example. I had =dev-lang/python-2.3.3 in my world file because I have a production app that relies on python and I didn't want to accidentally break that app. However now python is slotted -- so I don't necessarily want to avoid installing python 2.4 -- I just don't want my 2.3.3 to get changed. I see from http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3 that I can use the package.unmask file to override masked packages. I imagine that I could do something like >dev-lang/python-2.4 in the /etc/portage/package.unmask file -- so that I would effectively be masking versions of python greater than 2.3.3 but less than 2.4. However then I'd end up unintentionally unmasking legitimately masked unstable ebuilds in the 2.4 and later version range. I presume I could go in and mask ebuilds explicitly with '=' statements in the package.mask file. However that would then need to be updated everytime someone releases a new revision of an ebuild -- fragile an unmaintainable. What is the right way to tell portage to leave a particular version alone when doing emerge world? Cheers, Chris
Okay. I've seen enough bugs now to warrant a place-holder.
Jason, I notice you just changed the summary on this bug. It sounds like you are thinking of implementing the ability to pin packages with a new file rather than in the world file. Could you provide a quick summary of what you have in mind or point me to a mailing list message or glep with the details. Thanks much! Cheers, Chris
package.prefer would be a file with the same syntax as package.mask or package.unmask. Any package that's a candidate for an upgrade or downgrade and matches an atom in package.prefer would be shown (and marked) in --pretend output but would not be updated.
Jason, Thanks for the response. I like the idea. In the summary you called it package.defer and in your statement you called it package.prefer. I like package.prefer personally. I think it is more clear. I'll watch this bug for activity -- I'd love to help with early testing of this. Cheers, Chris
package.defer.. prefer is another idea. Or in other words, "defer" can change but "prefer" is already taken.
Jason, Responded too early this morning -- before my caffine. How would this interact with slots? If I understand correctly package.defer would have the same functionality as pacakge mask but just different notification. Wouldn't this have the same problem of preventing the addition of a newer slotted version? Cheers, Chris
*** This bug has been marked as a duplicate of 47456 ***
