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@g.o mailing list