I know that the -U Flag in emerge is a realy nasty thing and I don't want it back. I searched for similar enhancement requests in bugzilla but found none. I would like to have a similar posibility to easy install unstable packadges as without adding ACCEPT_KEYWORDS and pushing the ebuild in packages.keywords allthe time, and with the tendencie that my system tries to get stable if it can. I suggest to reuse the -U Flag. The meaning would be change then from --Upgradeonly to --Unstable. When this flag is used and the package emerged is not equal world, emerge adds automaticly all packages to packages.keywords. The line added aims at adding unmask one version only and should be something like =ebuild_name-version.number ~arch With this feature at hand it should be possible at emerge sync checks package.keywords after an update and delete all lines which have a updated version equal or greater the one entered in packadge.keywords. With that a system would regenerate itself to become a stable system again. Advantages: The hole unstable is still in reach but it is just transient. The system tries to get stable by itself. more secure use of the unstable tree. You still has to sanktion the installation of unstable packadges. disadvantages complexity of implementation. Now at least I believe (in my own ignorance) it could be done.;) what do you think is this possible to do? I would try myself but no time atm. Thanks for your comments and for reading :) Reproducible: Always Steps to Reproduce: The steps done by emerge 1.# emerge -U package.ebuild OUTPUT: Warning you are tryng to install unstable packadges on a stable system adding --ask [ N ] package.ebuild-1.0 Are you sure you want to install? (yes/no) 2. File package.keywords "=subfolder/package.keywords-1.0 ~arch" is added 3. Installation starts After a while the package 1.3 became stable 1.emerge sync the new ebuild got downloaded 2. emerge checks in the package.keywords for the line =subfolder/package.keywords-1.0 ~arch 3. checking package.ebuild status package.ebuild 1.0 <= 1.3 true 4. line gets deleted next time update the packadge gets updated and is stable again
This should be an external tool imo. Further, with this proposal, it's indeterminate- do you just p.keyword all deps that are *missing* and must be installed, or just the target? What if the target needs an unstable dep? Questions like this are why -U is a bad thing...
unstable packadges are general not good to a stable system, aren't they? The initial problem is, if I Install a unstable app it will stay unstable as long as i do not look manualy if a stable target exists. This gets quite nasty fast. Since this hole is a very dangerous theme I suggest to add automaticly the --ask flag and print out a seperate Warning. >What if the target needs an unstable dep? I would suggest it is automaticly added to the list. The hole stuff gets a bit complicated when the app which is installed needs a unstable dependecies which we have as stable. In this case best stuff would be that portage automaticly tries to open a new slot. But how to resolve this again I realy lack of experience. Maybe it is a good Idea to seperate it to an own tool(kit), it would then not interfere with the normal emerge development.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Closing as WONTFIX: This has been discussed to death already, and there are several 3rd-party scripts doing this.
