| 1 |
On Wed, Jan 16, 2013 at 7:00 PM, Michael Weber <xmw@g.o> wrote: |
| 2 |
> how does portage @preserved-libs work? maybe we could emerge |
| 3 |
> @update[s] and @glsa. |
| 4 |
|
| 5 |
@glsa actually makes a lot of sense. I'm not convinced we want |
| 6 |
@updates as a shortcut for a bunch of settings though. Sets are just |
| 7 |
about picking which packages to operate on, and overloading them in |
| 8 |
this way is going to just lead to confusion. Sets should be nothing |
| 9 |
more than lists of packages, and then the other emerge parameters can |
| 10 |
be used to filter them. |
| 11 |
|
| 12 |
I'd just stick with a simple parameter like --upgrade or an |
| 13 |
alternative command name like emerge-update. |
| 14 |
|
| 15 |
Oh, here's another crazy thought. How about some directory in /etc |
| 16 |
that sets rules for emerge-update (or whatever we call it)? You might |
| 17 |
have a bunch of low-numbered rules that set/append variables like |
| 18 |
EMERGE_DEFAULT_OPTIONS, and then a bunch of higher-numbered rules that |
| 19 |
actually run commands. Then if you install eix or layman they could |
| 20 |
stick a hook in there to trigger their own respective updates. A |
| 21 |
downside is that it makes the behavior of the command a bit less |
| 22 |
predictable. An upside is that the behavior of the command will only |
| 23 |
change subject to config file protection (well, sort-of - additional |
| 24 |
rule files don't typically trigger protection). |
| 25 |
|
| 26 |
Rich |
Archives