From: James <wireless@tampabay.rr.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: kde4 upgrading
Date: Wed, 28 Oct 2009 00:28:43 +0000 (UTC) [thread overview]
Message-ID: <loom.20091028T010741-743@post.gmane.org> (raw)
In-Reply-To: 200910280024.30685.alan.mckinnon@gmail.com
Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
> 4.3.2 seems to work fine for most folk. These days it's X causing grief, not
> KDE...
OK, so I keep the system locked down on X (that it is using) and just
deal with kde4 for now.
> Pick the primary workstation and get that one right, either using sets you
> like or the -meta packages.
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.......
> x11-terms/clusterssh is your friend here:
> configure it to log into all your workstations;
> launch it;
> what you type is sent to every workstation
> aka how-to-update-many-machines-in-parallel
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.
Granted, I have various CPU arch (intel or amd64)
different video hardware and various X and drivers that
contributes. But chasing down packages in sets and dealing
with the daily dynamic (every few days a different issue)
is just too much for me. META_MAN is my hero!
How long is kde-meta going to be around?
That's really what I'm looking for.....
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.
James
next prev parent reply other threads:[~2009-10-28 0:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-27 16:13 [gentoo-user] kde4 upgrading James
2009-10-27 22:24 ` Alan McKinnon
2009-10-27 22:47 ` Frank Steinmetzger
2009-10-28 0:30 ` [gentoo-user] " James
2009-10-27 23:54 ` [gentoo-user] " Neil Bothwick
2009-10-28 0:28 ` James [this message]
2009-10-28 4:37 ` [gentoo-user] " Jonathan Callen
2009-10-28 8:58 ` Alan McKinnon
2009-10-28 13:44 ` Stroller
2009-10-29 14:59 ` [gentoo-user] Re (DONE): " James
2009-10-29 17:53 ` Stroller
2009-10-29 19:17 ` Alan McKinnon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20091028T010741-743@post.gmane.org \
--to=wireless@tampabay.rr.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox