Jorge Manuel B. S. Vicetto wrote:
Those using paludis need just to run[1]: ~ paludis -pi1 compiz-fusion --dl-reinstall-scm always --compact \ ~ --show-reasons none
and what about # emerge @compiz [1] Simpler isn't it? Or # emaint -r world[2] # emerge -u compiz-fusion [1] you you can do that right now. [2] possible way to trigger regeneration, extended to sets if interesting.
So, running a reinstall with a world update is not desirable and having to manually mask/unmask live ebuilds can also be a mess.
Agreed.
Having a method that lets the user choose to reinstall all the live ebuilds every N days is an interesting option. Having a method that lets the user choose that the PM should check the scm tree and update the package if there's a new revision would be even better.
so something like #emerge -uL compiz-fusion is what you'd like better.
One option that might be interesting to avoid having the PM update *all* live deps, would be to have an option to run the update for packages inside a set. In this case, for example, I could just add all the compiz packages to a set and not worry about the PM updating also all the live kde packages.
right now you can add all the compiz packages to a set and just issue and emerge @compiz and archive what you want ^^
Another case where having a method to let PMs identify "live" ebuilds is important is for running QA scripts like repoman or pcheck. Instead of having pcheck complain about dropped keywords for version 9999, I would like to have pcheck complain about "live" ebuilds with keywords. Not all "live" trees are unstable and thus some might not like this change. However, if a PM is able to determine "live" ebuilds, it might be easier to have alternative tests that allow testing for dropped keywords or for the existence of keywords just for "live" ebuilds.
Agreed. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
