Hello, I would find it very useful if emerge would use an additional subdirectory e.g. /usr/portage/myEbuilds and an additional package.mask e.g. /usr/portage/myEbuilds/myPackage.mask where a user could place his own ebuilds and an additional .mask file. The additional .mask file would enable the user to mask existing ebuilds, therefor emerge would use ebuilds find in myEbuilds. E.g. with that construct, I could place an ebuild cyrus-sasl-2.1.2.ebuild in myEbuilds/dev-libs/cyrus-sasl (or myEbuilds/cyrus-sasl) and would mask out all other versions. I would find this very handy, because now, I have to copy my ebuild(s) into the portage tree after every rsync (--clean). I don't need to mention, that myEbuilds an myPackage.mask should touched with rsync. ;) I think this shouldn't be much work, and would be a nice feature. Regards, Alexander
Hi, I think these ideas are very useful, and I have an additional suggestion: A personal antimask file, where I can put package names of masked packages to have them permanenty unmasked. This would be very useful if someone decides to take part in long-time-testing a package that was masked because it had not enough testing. I had this idea because I have to remove giFT out of the mask after every rsync to check for an updated version. jk
I've just got another idea, maybe it would be useful if any ebuild in myEbuilds would allways prefered before any other ebuild in the normal portage. E.g. if I had an cyrus-sasl-2.1.2.ebuild in myEbuilds this should be allways used instead of any other version. It would be more flexible if emerge would use a subdirectory e.g. named myEbuilds/prefered and only ebuilds in that directory should prefered.
I'm using bug 5622 to track these requests. We have local portage tree support (beta) in Portage 2.0.21+. *** This bug has been marked as a duplicate of 5622 ***
