From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display
Date: Sun, 23 Nov 2008 13:10:25 +0000 (UTC) [thread overview]
Message-ID: <pan.2008.11.23.13.10.24@cox.net> (raw)
In-Reply-To: d257c3560811230356l13b249cfm8fd974dfc493b094@mail.gmail.com
Beso <givemesugarr@gmail.com> posted
d257c3560811230356l13b249cfm8fd974dfc493b094@mail.gmail.com, excerpted
below, on Sun, 23 Nov 2008 11:56:36 +0000:
> with portage i had very often issues with having the deps discovered
> in the right way. of course when the system is up and running this
> isn't so much of a trouble, but when you set it up or when
> you do an upgrade that still has quite some deps discovered then the
> problem is to be seen.
Hmm... I've never had a major problem in that regard. At least not since
my initial from-stage-one installation back with 2004.0 (first try)
and .1 (actual success). But portage is so changed since then it's
really not worth considering, and it could have just as easily been my
goofs, I know I was learning a quite a bit as I went, or bad ebuilds.
Other than that, there has been perhaps an occasional minor niggle, but
nothing someone running ~arch shouldn't expect from time to time and be
able to work out or revert to a working version (perhaps the known
working version on the rootbak image, snapshot taken when the system was
in known bootable and reasonably stable condition) should it be necessary.
Personally, however, I suspect that stable isn't really that much more
stable than ~arch, and the fact that my portage stub-scripts for @world
and @system all use -aNuDv so I get a preview, deep dependencies don't
get behind and USE flag changes get managed right away, plus routine use
of revdep-rebuild and --depclean, possibly none of which those on stable
are likely to do regularly let alone religiously, has a lot to do with my
relatively smooth ride, even on ~arch.
> well, anyway, i always find good having
> at least 2 working package installers
I saw that point made a few days ago and thought it was a good one. Of
course, if I were to do it given my stated position, I'd be merging
pkgcore instead. However, I've a decent enough familiarity with portage
that in some cases at least, it's easier to actually work the problem,
than it would be to learn my way around a second PM.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2008-11-23 13:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-23 7:23 [gentoo-amd64] kde4, xorg, xf86-video-ati/radeon, and multi-panel display Duncan
2008-11-23 10:20 ` [gentoo-amd64] " ABCD
2008-11-23 11:00 ` ABCD
2008-11-23 11:03 ` Beso
2008-11-23 11:39 ` Duncan
2008-11-23 11:56 ` Beso
2008-11-23 13:10 ` Duncan [this message]
2008-11-23 11:06 ` Duncan
2008-11-23 11:38 ` Beso
2008-11-23 12:33 ` Duncan
2008-11-23 11:24 ` [gentoo-amd64] " Beso
2008-11-23 12:08 ` [gentoo-amd64] " Duncan
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=pan.2008.11.23.13.10.24@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-amd64@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