1 |
On Tue, Oct 13, 2009 at 11:43:49PM +0200, Branko Badrljica wrote: |
2 |
> Which I did. I don't have openrc in /etc/portage/package.use, so it was |
3 |
> emerged with default USE flags ( if you count default as in "as set in |
4 |
> make.conf" ). emerge -pv openrc woould emerge it as: |
5 |
> |
6 |
> sys-apps/openrc-0.5.1 [0.4.3-r4] USE="ncurses oldnet%* pam unicode -debug" |
7 |
> |
8 |
> ... which means with "oldnet" flag. |
9 |
|
10 |
In that case, if your system was broken, I'm sure the maintainers would |
11 |
like to know about and would like to know how you fixed it, since it |
12 |
was a different issue. |
13 |
|
14 |
> And whenever I tried it, it broke my system. |
15 |
|
16 |
Please file a bug. |
17 |
|
18 |
We need to know all steps and all details of what happened when you did |
19 |
the upgrade. Did you use etc-update or something similar to update all |
20 |
of your configuration files? What happened when you attempted to |
21 |
reboot? From what you described in your original email there is not |
22 |
enough information to tell us what was going on. |
23 |
|
24 |
> > If you accept the defaults and it doesn't work, I will gladly agree that |
25 |
> > there is a major regression and the package should be masked. On the |
26 |
> > other hand, if the new network scripts do not work, I don't see that as |
27 |
> > a show stopper. Yes, I would agree that there should be a warning about |
28 |
> > turning off the oldnet use flag, but I don't think this warrants masking |
29 |
> > the ebuild, unless I am missing something. If I am, definitely let me |
30 |
> > know. |
31 |
> I don't feel comfortable with your philosophy. It doesn't matter how |
32 |
> obvious matters seem to you, your changes can affect many people in many |
33 |
> situations and configurations, not necessarily allways without unforseen |
34 |
> consequences. |
35 |
|
36 |
Agreed. However, it is also impossible for developers to test packages |
37 |
on every possible system with every possible configuration, so there |
38 |
will be times, if you are running ~arch, that things may not work right. |
39 |
If that happens, the best thing you can do is file a bug so that we can |
40 |
try to fix the issue. |
41 |
|
42 |
As was said earlier in this thread, the person who put it in the tree |
43 |
tested it, and he had several others test it with no problems. Also, he |
44 |
did follow upstream's recommendation and configure the new openrc to use |
45 |
the old network scripts. So, if there is an issue, we need to know |
46 |
about it. |
47 |
|
48 |
> I understand that Gentoo is not for pussies and that you can't make an |
49 |
> ISO-9001 procedure for every change with every user, but it would really |
50 |
> be nice to have at least some _basic_ safety, like mentioning changes in |
51 |
> eselect news, or at least on home page of the package. |
52 |
|
53 |
I'm sure that any documentation issues will be taken care of by the time |
54 |
the package goes stable. |
55 |
|
56 |
For the record, I am not a maintainer of openrc either, but my |
57 |
experience was that that there was no change to be made since I stayed |
58 |
with the old network scripts. Like I said above, maybe there should |
59 |
have been a warning to not try to switch to the new scripts yet unless |
60 |
you were willing to test them, but I don't see why it should have |
61 |
prevented ~arch users from getting the package. |
62 |
|
63 |
|
64 |
-- |
65 |
William Hubbs |
66 |
gentoo accessibility team lead |
67 |
williamh@g.o |