On Saturday 11 July 2009 20:32:19 William Hubbs wrote: > Hi Alan, > > On Sat, Jul 11, 2009 at 07:28:24PM +0200, Alan McKinnon wrote: > > On Saturday 11 July 2009 19:24:35 Andrew Gaydenko wrote: > > > > Find the ebuild in /var/db/pkg/category/package > > > > > > Thanks, it works - just created Manifest also. > > > > It's pity that portage doesn't support the .deb concept of pinning. I > > know you can always achieve the same effect with masks, but it would be > > nice to be able to say "hold package XYZ at current version" and be done > > with it. It happens often enough to be useful. > > You might want to take a look at man 5 portage, in particular, the > section on /etc/portage/profile/package.provided. If you list a full > package atom with a version in there, portage will not bother you about > upgrading that package, and you do not have to keep the ebuild around > in a local overlay. > > Does this do what you are trying to do?
This little snippet from --depclean is enough to make me never use package.provided with a package from an ebuild: # emerge -a --depclean * Always study the list of packages to be cleaned for any obvious * mistakes. Packages that are part of the world set will always * be kept. They can be manually added to this set with * `emerge --noreplace <atom>`. Packages that are listed in * package.provided (see portage(5)) will be removed by * depclean, even if they are part of the world set. AFAIK, package.provided is for use with apps that are in portage but for whatever reason the user has decided to install them by other means. package.provided is a way to satisfy deps of that package without having it installed via an ebuild. The solution you propose does require installation via an ebuild. -- alan dot mckinnon at gmail dot com
