I would find it great, if emerge could automatically accept installed packages. I have more and more the problem that I have to use ~ packages (I won't call them unstable) which by themself are having dependencies to ~ packages. The problem now is, that this brakes emerge world, because it can't find the needed dependencies. And ACCEPT_KEYWORDS="~arch" emerge world isn't a solution. So I would find it great, if emerge just could accept all installed package-versions (by option --accept-installed) . This would solve the problem. Kind regards, Alexander
use /etc/portage/package.keywords (man portage)
This is no solution. If I have to maintain a list of packages which I emerged with ACCEPT_KEYWORDS="~arch" because no one wants to mark them stable, the I soon start using checkinstall or rpm. If you don't want feature request, remove that possibility or mark them as "no time". But invalid is definitely wrong.
accepting of unstable packages on a stable system (or vice versa) is done mostly on a per package basis ... if you have so many unstable packages on your system that this is a 'burden', then maybe you should review whether you should be running unstable as for maintaining /etc/portage/package.keywords, i really dont see that as being a 'burden' ... one entry for each package ? unless nick disagrees, i see this as a WONTFIX
I'm using it on a "per package" basis. If I need an "unstable" ebuild I just do a USE="~arch" emerge package. So I have control over which version from an unstable package I use. Quick and without the need to maintain a list. And if the package or a newer version will become stable, I have no need to change anything. The only problem arises, when I make a emerge --deep -uU world. Then emerge doesn't accept installed "unstable" packages. With something like --accept-installed (for the installed version of the installed package) this would be easy avoided (because I allready have given emerge the permission to install that unstable version). And I think it isn't a great task to implement that switch, but I haven't any knowledge of the emerge-source. So I still think that with a small amount of work, many users would have a benefit (because there would normally no need to maintain an allways changing list of unstable package-version one uses).
I don't see the problem you have with package.use... It's a lot more convenient than a db-stored list of packages and it's not something you forget to turn on and get mad at portage about. It requires less work for me, gives you a ready-to-view listing of everything you've set, and isn't subject to you forgetting. It does what you want. It might be inconvenient for you to have to set up right now, but I'm sure it won't take more than 10 minutes and you'll have a solution.
Hmm, either you don't understand what I mean, you won't understand what I mean or nobody is interessted in usability. I will explain it again: I will use a newer version than the last marked as stable: USE="~x86" emerge alsa-lib alsa-utils Now I do a emerge --deep -puU world: These are the packages that I would merge, in order: Calculating world dependencies - !!! all ebuilds that could satisfy ">=media-libs/alsa-lib-1.0.3" have been masked. !!! possible candidates are: - media-libs/alsa-lib-1.0.3b-r2 (masked by: ~keyword) - media-libs/alsa-lib-1.0.3b-r1 (masked by: ~keyword) !!! (dependency required by "media-sound/alsa-utils-1.0.3" [ebuild]) !!! Problem with ebuild media-sound/alsa-utils-1.0.3 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. Your solution is now to enter an entry for at least for alsa-lib in package.keywords. This isn't something I would call nice to do. And if a newer version becomes stable the entry becomes unecessary. So after sometime I have a great outdated list of package names and ebuild versions (if I don't want to maintain that list). Maybe nice for a history of unstable ebuilds I once installed. ;) And I still don't see the problem. Emerge already knows that I have given him the permission to install a particular version. So marking it as 'allowed to install (again)' shouldn't a great problem. But 'WorksForMe' is ok. "./configure;make;make install" works to. ;)
