| 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 |
Archives