| 1 |
Alan McKinnon <alan.mckinnon <at> gmail.com> writes: |
| 2 |
|
| 3 |
|
| 4 |
> 4.3.2 seems to work fine for most folk. These days it's X causing grief, not |
| 5 |
> KDE... |
| 6 |
|
| 7 |
OK, so I keep the system locked down on X (that it is using) and just |
| 8 |
deal with kde4 for now. |
| 9 |
|
| 10 |
|
| 11 |
> Pick the primary workstation and get that one right, either using sets you |
| 12 |
> like or the -meta packages. |
| 13 |
|
| 14 |
|
| 15 |
kde-meta is ideal for me. I thought it was going away? |
| 16 |
Since kde(4)-meta is alive and well, that is my preferred |
| 17 |
method. I hope when kde-meta goes away (?) there is a migration |
| 18 |
plan? When this whole kde4 venture started for me (feb 09) |
| 19 |
I was told to avoid meta as it is going away....... |
| 20 |
|
| 21 |
|
| 22 |
> x11-terms/clusterssh is your friend here: |
| 23 |
> configure it to log into all your workstations; |
| 24 |
> launch it; |
| 25 |
> what you type is sent to every workstation |
| 26 |
> aka how-to-update-many-machines-in-parallel |
| 27 |
|
| 28 |
|
| 29 |
Interesting, but not what I'm looking for. I do not mind |
| 30 |
upgrading the systems one at a time. I just do 1 per day, |
| 31 |
while I do other work. What has me "hacked" is that every time |
| 32 |
I do an upgrade to kde4, it seems to be a different set |
| 33 |
of problems, even though the upgrades are a few days apart. |
| 34 |
Multiply across a dozen workstations, and it's a time sink. |
| 35 |
Granted, I have various CPU arch (intel or amd64) |
| 36 |
different video hardware and various X and drivers that |
| 37 |
contributes. But chasing down packages in sets and dealing |
| 38 |
with the daily dynamic (every few days a different issue) |
| 39 |
is just too much for me. META_MAN is my hero! |
| 40 |
|
| 41 |
|
| 42 |
How long is kde-meta going to be around? |
| 43 |
That's really what I'm looking for..... |
| 44 |
|
| 45 |
PS, if one of you really smart guys figures out mass/parallel |
| 46 |
upgrades, then I'd use that, even set up my own server |
| 47 |
to keep it efficient. I'm not smart enough (not enough time |
| 48 |
at current mental aptitude) to set all of that up, unless |
| 49 |
somebody else does the foundational work..... |
| 50 |
|
| 51 |
But I very much like the concept. Upgrade a master system. |
| 52 |
Test it. Then push your own binaries/files to the other systems |
| 53 |
you manage. Somebody figures that out, i.e. works out the bugs, |
| 54 |
Gentoo is going mainstream...... If someone did that, they could |
| 55 |
just put their admin scripts and settings in an ebuild. Then users |
| 56 |
could just emerge that ebuild and set the list of installed packages. |
| 57 |
VERY COOL. |
| 58 |
|
| 59 |
|
| 60 |
|
| 61 |
|
| 62 |
James |
Archives