kde4 upgrading
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James wrote:
> kde-meta is ideal for me. I thought it was going away?
> Since kde(4)-meta is alive and well, that is my preferred
> method. I hope when kde-meta goes away (?) there is a migration
> plan? When this whole kde4 venture started for me (feb 09)
> I was told to avoid meta as it is going away.......
>
> [...]
>
> How long is kde-meta going to be around?
> That's really what I'm looking for.....
>


kde-base/kde*-meta won't be going away any time soon, if at all. The
original plan, way back when, was to transition everything to sets, but
the current implementation in portage 2.2_rc* does not currently do
everything that is needed, so we are recommending the usage of the meta
packages.

- --
Jonathan Callen
Gentoo KDE Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrnym4ACgkQOypDUo0oQOo9ZQCbBwM1fUMQzv +mReF/aaEkr8I7
LLUAmgIaNDiixVl5fd+PQY2OjqMPY1pU
=icEh
-----END PGP SIGNATURE-----

kde4 upgrading
 

On Wednesday 28 October 2009 02:28:43 James wrote:
> PS, if one of you really smart guys figures out mass/parallel
> upgrades, then I'd use that, even set up my own server
> to keep it efficient. I'm not smart enough (not enough time
> at current mental aptitude) to set all of that up, unless
> somebody else does the foundational work.....
>
> But I very much like the concept. Upgrade a master system.
> Test it. Then push your own binaries/files to the other systems
> you manage. Somebody figures that out, i.e. works out the bugs,
> Gentoo is going mainstream...... If someone did that, they could
> just put their admin scripts and settings in an ebuild. Then users
> could just emerge that ebuild and set the list of installed packages.
> VERY COOL.
>

All that already exists and is fully supported by portage. Build your packages
on one central machine and pull them from the workstations.

"man emerge" and search for BINHOST.

The only catch is to define the various settings (USE, CHOST, CFLAGS) to
something compatible with all your machines. This is not a big deal, it's the
kind of decisions a binary distro must make and those work fine


--
alan dot mckinnon at gmail dot com

kde4 upgrading
 

I've edited your message when quoting it in order to meet my agenda.

On 28 Oct 2009, at 00:28, James wrote:

....
PS, if one of you really smart guys figures out mass/parallel
upgrades, then I'd use that, even set up my own server
to keep it efficient. I'm not smart enough (not enough time
at current mental aptitude) to set all of that up, unless
somebody else does the foundational work.....

But I very much like the concept. Upgrade a master system.
Test it. Then push your own binaries/files to the other systems
you manage.


There are already a number of ways of managing multiple machines. How
do you think universities, corporations and public bodies with
hundreds or thousands of desktops manage? I think I would be looking
at something like having the machines PXE boot a single image or NFS
mounting various directories, if I were in your situation. I've never
actually done this, but I'm sure a little research would produce a
less labour intensive solution.



...
Interesting, but not what I'm looking for. I do not mind
upgrading the systems one at a time. I just do 1 per day,
while I do other work. What has me "hacked" is that every time
I do an upgrade to kde4, it seems to be a different set
of problems, even though the upgrades are a few days apart.
Multiply across a dozen workstations, and it's a time sink.


It seems to me, from your description, that your dozen machines are at
the limit of your ability to maintain this way. No one would ever
consider upgrading sites with 100 machines one by one each day, and it
would be crazy to try and run a beefy thin-client server just to serve
one or two desktops.


So the network has grown from a couple of machines to a dozen, and
you're still doing things the same way - the question is, will you be
able to continue doing things the same way if you were to double the
number of PCs by next year?


I think that alternative methods of approaching system administration
are sure to bring their own problems and require an investment of time
to implement, but I don't see how upgrading machines one by one is
sustainable. Honestly, it would be driving me crazy to be in your
position, and I think some other alternative might well show time and
hassle saved once it's up and running.


Stroller.