| 1 |
On Tue, 2004-11-16 at 18:18 +0100, Alexander Gretencord wrote: |
| 2 |
> > but at the same time, how many of you don't know that we put messages in the |
| 3 |
> > ebuilds that you should follow? |
| 4 |
> |
| 5 |
> Many probably don't want to look at them inside the ebuild, because there |
| 6 |
> should be a mechanism to show important information when doing an "emerge |
| 7 |
> world", else emerge world has to be removed. |
| 8 |
|
| 9 |
I meant the nice little einfo, ewarn, and error stuff that portage spits |
| 10 |
out that we insert into the ebuilds. Nobody expects you to read the |
| 11 |
ebuild itself. |
| 12 |
|
| 13 |
> > How many of you simply ignore them anyway and do an "emerge -uD world" |
| 14 |
> > blindly and don't pay any attention to the nice messages we worked so |
| 15 |
> > hard to put into the ebuilds? |
| 16 |
> |
| 17 |
> Many, me included, because I simply can't be bothered to look at the output |
| 18 |
> all the time, waiting for the X seconds that I have time to read a msg. I |
| 19 |
> start a screen session on the server, look at "emerge world -vp", decide |
| 20 |
> which packages to really upgrade, start a merge for them and close my |
| 21 |
> terminal. If there is important information, there has to be a way for emerge |
| 22 |
> to tell me, without me, waiting for 20 ebuilds to run by, while I stare at |
| 23 |
> the screen! And this mechanism should not be "have a logfile somewhere so I |
| 24 |
> can read it if I know about it", I at least want to have a message like |
| 25 |
> "important information about the last merged ebuilds is available in file |
| 26 |
> XXX, have a look at it" beneath my merge. On the other hand, if this is |
| 27 |
> possible you can just as easily put the information itself on screen (while |
| 28 |
> still saving it to a file, for the case when the screen buffer was too small |
| 29 |
> to capture everything). |
| 30 |
|
| 31 |
You "simply can't be bothered" so that means we should all jump to not |
| 32 |
only help, but encourage your laziness and apathy? |
| 33 |
|
| 34 |
While I understand everyone's need to have their hand held every second |
| 35 |
of the day by the whole of Gentoo, it really is not *our* fault when |
| 36 |
*you* do actions that prevent you from reading the messages that we do |
| 37 |
give you. |
| 38 |
|
| 39 |
> > However, I said to myself "Hrrmn... It seems hotplug is broken. Perhaps I |
| 40 |
> > should read the ChangeLog and see what it says there?" and all was right in |
| 41 |
> > the universe again. |
| 42 |
> |
| 43 |
> Thats what I would do too, however, this is not the right solution to the |
| 44 |
> problem from a users/admin perspective. The solution is to give the |
| 45 |
> user/admin the tools to be notified of important changes automatically. In a |
| 46 |
> way that makes sure that you are really able to view the information. |
| 47 |
|
| 48 |
You mean like piping the output of emerge to mail or sendmail? That |
| 49 |
seems easy enough... or how about redirecting the output to a file? I |
| 50 |
mean, surely that is so hard to do that we need to force this action |
| 51 |
upon everyone, right? |
| 52 |
|
| 53 |
My entire point here is that no matter what we do, someone will come up |
| 54 |
and complain that it doesn't do what they want it to do. I have a |
| 55 |
simple solution for this. Do it how you want... you don't need us to do |
| 56 |
it for you. |
| 57 |
|
| 58 |
If you are blindly upgrading packages *knowing* that there could be |
| 59 |
changes in those packages that would affect you and you do nothing to |
| 60 |
even verify that nothing will adversely affect your setup, then no |
| 61 |
amount of hand-holding will help you. I mean that the people that |
| 62 |
complain about their systems being broken because they didn't follow the |
| 63 |
instructions that we have laid out for them are a vocal minority. When |
| 64 |
changes like this happen, there is usually *very* little repercussions |
| 65 |
and almost no bug reports. |
| 66 |
|
| 67 |
Now, with that being said, I will *gladly* add this support to portage |
| 68 |
just as soon as somebody decides to start paying me a salary equivalent |
| 69 |
to my current one so I can hack on Gentoo all day long just to add a |
| 70 |
bunch of little "hold my hand and wipe my ass for me" features rather |
| 71 |
than working to add support for new devices and applications. |
| 72 |
|
| 73 |
> > Unfortunately, there really is only so much hand-holding that we can |
| 74 |
> > accomplish as developers and still have time to actually *work* on the |
| 75 |
> > distribution. |
| 76 |
> |
| 77 |
> Have a look at the bugreport mentioned in the message I refer to earlier. |
| 78 |
|
| 79 |
No thanks... I'll leave that up to the portage team and get back to |
| 80 |
working on things that I find interesting. |
| 81 |
|
| 82 |
-- |
| 83 |
Chris Gianelloni |
| 84 |
Release Engineering - Operational/QA Manager |
| 85 |
Games - Developer |
| 86 |
Gentoo Linux |
Archives