From: Mark Knecht <markknecht@gmail.com>
To: Gentoo AMD64 <gentoo-amd64@lists.gentoo.org>
Subject: Re: [gentoo-amd64] Re: amd64 list, still useful? Was: btrfs
Date: Thu, 5 Jun 2014 11:59:23 -0700 [thread overview]
Message-ID: <CAK2H+eff_N8GzHnLWYNXA4nDQGuXGSyFyOptgFuUZfE5wV7UFA@mail.gmail.com> (raw)
In-Reply-To: <pan$ead40$2155f9ba$4581fb0d$d750b36d@cox.net>
On Wed, Jun 4, 2014 at 7:00 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Mark Knecht posted on Wed, 04 Jun 2014 09:41:30 -0700 as excerpted:
>
>> There is an in progress, higher energy thread on gentoo-user with folks
>> getting upset (my interpretation) about systemd and support for
>> suspend/resume features. I only found it being that I ran into an emerge
>> block and went looking for a solution. (In my case it was -upower as a
>> new use flag setting.)
>
> Yeah. I saw the original dev-list thread on the topic, before it all hit
> the tree (and continuing now), which is a big part of why I subscribe to
> the dev-list, to get heads-up about things like that.
>
Maybe all Gentoo users should subscribe! Over time we would likely
all get a bit smarter. ;-) ;-) ;-)
> What happened from the dev-list perspective is that after upower dropped
> about half the original package as systemd replaced that functionality,
> the gentoo maintainers split the package in half, the still included
> functionality under the original upower name, with the dropped portion in
> a new, basically-gentoo-as-upstream, package, upower-pm-utils.
>
I certainly have no issue with the basics of what they did, but more
in a second.
> But to the gentoo maintainer the portage output was sufficient that
> between emerge --pretend --tree --unordered-display and eix upower, what
> was needed was self-evident, so he didn't judge a news item necessary.
> What a lot of other users (including me) AND devs are telling him is that
> he's apparently too close to the problem to see that it's not as obvious
> as he thinks, and a news item really is necessary.
>
Yeah, this was likely the issue. One comment in the -user thread on this
subject was that at least one -dev-type thinks users should be reading
change logs to figure this stuff out. I no longer remember how long I've
run Gentoo but it's well beyond a decade at this point. Daniel Robbins
was certainly participating. I was working at a company from mid-1999
to 2004 when I started. I can only say that I've never read a change log
in that whole time.
> Compounding the problem for users is that few users actually pulled in
> upower on their own and don't really know or care about it -- it's pulled
> in due to default desktop-profile use-flags as it's the way most desktops
> handle suspend/hibernate.
As is the case for me using kde-meta. However while I figured out I could
set -upower on kdelibs and not have any build or boot issues pretty quickly
I soon discovered that flag goes beyond my simplistic view of
suspend/resume which I have never used. It also covers _everything_ in
the Power Management section of systemsettings which means I lost
my ability in KDE to control what I suspect is DPMI time settings on
my monitors. I'll either have to learn how to do that outside of KDE or
reinstall the newer upower-pm-utils package.
> Further, certain desktop dependencies
> apparently got default-order reversed on the alternative-deps, so portage
> tries to fill the dep with systemd instead of the other package.
> Unfortunately that's turning everybody's world upside down, as suddenly
> portage wants to pull in systemd *AND* there's all these blockers!
>
Yeah, that's what got me to look at gentoo-user and find the problem. Lots
of blocks involving systemd.
<SNIP>
> So things should really be simmering back down pretty shortly. =:^)
> Meanwhile, in the larger perspective of things, it's just a relatively
> minor goof that as usual is fixed in a couple days. No big deal, except
> that /this/ goof happens to include the uber-lightening-rod-package that
> is systemd. Be that as it may, the world isn't ending, and the problem
> is indeed still fixed up within a couple days, as usual, with
> information, some reliable, some not so reliable, available via the usual
> channels for those who don't want to wait.
>
This stuff does happen once in awhile. I'm surprised it doesn't happen
more often actually so for the most part the release process is pretty
good.
WRT to systemd, my real problem with this latest issue is the systemd
profile issue, and beyond that there doesn't seem to be a systemd
oriented new machine install document. In my study getting ready to
build a new RAID (probably will be 2-drive 3TB RAID1) I wondered
of I should give in to this portage pressure and go systemd. When
I start looking there all I find are documents that seem to assume
a pretty high understanding of systemd which doesn't represent
my current education or abilities. Seems to me if the gentoo-devs
interested in seeing systemd gain traction were serious this would be
a high priority job. All we get today is
http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1#book_part1_chap12
which to me says it's not what Gentoo developers want Gentoo users to
use. Of course, that's just me.
Take care,
Mark
next prev parent reply other threads:[~2014-06-05 18:59 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 22:13 [gentoo-amd64] Soliciting new RAID ideas Mark Knecht
2014-05-27 22:39 ` Bob Sanders
2014-05-27 22:58 ` Harry Holt
2014-05-27 23:38 ` thegeezer
2014-05-28 0:26 ` Rich Freeman
2014-05-28 3:12 ` [gentoo-amd64] btrfs Was: " Duncan
2014-05-28 7:29 ` thegeezer
2014-05-28 20:32 ` Marc Joliet
2014-05-29 6:41 ` [gentoo-amd64] " Duncan
2014-05-29 17:57 ` Marc Joliet
2014-05-29 17:59 ` Rich Freeman
2014-05-29 18:25 ` Mark Knecht
2014-05-29 21:05 ` Frank Peters
2014-05-30 2:04 ` [gentoo-amd64] amd64 list, still useful? Was: btrfs Duncan
2014-05-30 2:44 ` Frank Peters
2014-05-30 6:25 ` [gentoo-amd64] " Duncan
2014-06-04 16:41 ` [gentoo-amd64] " Mark Knecht
2014-06-05 2:00 ` [gentoo-amd64] " Duncan
2014-06-05 18:59 ` Mark Knecht [this message]
2014-06-06 12:11 ` Duncan
[not found] ` <Alo71o01J1aVA4001lo9xP>
2014-06-06 17:07 ` Duncan
2014-05-27 23:32 ` [gentoo-amd64] Soliciting new RAID ideas Mark Knecht
2014-05-27 23:51 ` Marc Joliet
2014-05-28 15:26 ` Bob Sanders
2014-05-28 15:28 ` Bob Sanders
2014-05-28 16:10 ` Rich Freeman
2014-05-28 19:20 ` Marc Joliet
2014-05-28 19:56 ` Bob Sanders
2014-05-29 7:08 ` [gentoo-amd64] " Duncan
2014-05-27 23:05 ` [gentoo-amd64] " Alex Alexander
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=CAK2H+eff_N8GzHnLWYNXA4nDQGuXGSyFyOptgFuUZfE5wV7UFA@mail.gmail.com \
--to=markknecht@gmail.com \
--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