On 11.03.2013 21:47, Volker Armin Hemmann wrote:
Am 11.03.2013 14:00, schrieb Yuri K. Shatroff:
[ quoting stripped ]
sorry for breaking in, but...
(to Volker Armin Hemmann)
1. If this driver is superfluous as you say, then why does it ever
exist in portage?
because it exists? gnome is there too. Or systemd AND openrc. mrxvt,
rxvt AND urxvt.
well, I guess, you won't have systemd AND openrc installed together even
if you try, that's what portage is for.
Is there any obstacle of using *rxvts together? I don't know but do not
think it critical.
and who's going to blame you for using gnome?
2. Since it does exist, then probably it would be much nicer to user
to show him a notice when he (user) tries to compile it on a kernel
which has native support for the device, or moreover an unsupported
kernel installed, than blame user for that?
no, this is gentoo. You are supposed to do your homework. No training
wheels.
Again, following your logic, why not just let the user himself
./configure && make && make install as in old days? What is portage for?
3. Why does the ebuild *not* check for supported kernel version or
breaking APIs/ABIs?
why should it? See above. You can't know if in the future something
might change.
That is a testing issue. Of course, one can never know what will change,
or whether the code contains a bug (before one is detected), but when
someone *does* stumble upon such issues, it is up to maintainers to
update portage to prevent the issue... that's what portage is for, isn't it?
That said, the topic starter has run across an issue and I assume the
action to be taken by the package maintainer is to add a test against
kernel compatibility and eligibility of the native driver, so that in
the future the issue not rise again. Am I right? Or do I completely
misunderstand the purpose of portage, and everything?
4. How and why would you expect to force all users to grep thru kernel
src in search for a driver they might need, especially when the
portage explicitly lists this driver? Also sometimes kernel drivers'
description is not quite consistent and it is not easy to figure out
whether it supports exactly yours card/chip/device, or moreover find
it by grep.
All kernel source? grep? Nope. Just reading a bit of help text. Maybe
using google. Doing it once.
As I said, there is not always good help text for kernel options.
Then you have a working setup you can use
for the rest of eternity (or the next couple of years...)
Okay, and when someone like the topic starter *did* have a working setup
with the "superfluous" driver from portage, ... do you feel the logic?
:) When should one realize that this setup is no more working? I guess,
just after it stopped working, right? :) Of course, again, if one is
really concerned he will check each kernel release or whatever for the
new stuff he's concerned about, but when all *worked*, why should he?
5. After all, linux and gentoo in particular are *not*
developer-only-oriented systems, and it is up to maintainers or
whomever to make them more user-friendly. Yes, it is not fair of a
user to blame someone for breaking APIs etc. but neither it is fair to
blame the user for not knowing everything as I bet nobody knows
everything about linux kernel.
oh, so gentoo is for ubuntu users? Well, why not use ubuntu in the first
place?
so, according to that, everyone who's striving to get
linux/gentoo/whtever more user-friendly (including portage's key
features) is an ubuntoid? You know, I came from FreeBSD where you're
supposed to do much more work by hand, and after a dozen years I'm a
little bit tired of that. I *can* do without things like portage's
colorful output, for example (although it's helpful most of the time).
But I really dislike things broken e.g. on `portupgrade -aR` and the
sort and I can *not* call a system which allows that a quality system.
That sort of user-friendliness has nothing to do with ubuntism ("we know
better what you want") and visual beauty: that's about quality.
(I know that there's no absolute quality, but when a system tends to
fail, and justifies that with "user not having googled or having taken a
way we, devs, didn't ever think to go" -- it's at least incorrect if not
arrogant.)
But I feel generous right now. You might have a point there. That does
not invalidate the 'remove kernels before testing' criticism from the
list nor does it solve the 'insisting to use the latest kernel release
instead of stable series' problem.
That's right, I was just feeling like the words you said towards the
topic starter were a little harsh, and wanted to have him a little
acquitted :)
--
Best wishes,
Yuri K. Shatroff
