| 1 |
On Wed, Oct 14, 2009 at 01:33:27AM +0200, Branko Badrljica wrote: |
| 2 |
> 1. Much of the time on Gentoo using of ~ packages is not user explicit |
| 3 |
> choice but forced compromise. |
| 4 |
> I don't remember exactly anymore what prompted me to enter openrc in |
| 5 |
> package.keywords, but I surely remember having a few headaches with it. |
| 6 |
> Same is with many other packages- many times using ~arch is the only |
| 7 |
> answer, so 99% of the time it is used for getting some package to work |
| 8 |
> and not for pure testing. |
| 9 |
|
| 10 |
The ~arch tree is where things go when they first enter the tree, and, |
| 11 |
if there are no issues with them for a period of time they are marked |
| 12 |
stable. Hard masking, on the other hand, generally is for packages that |
| 13 |
are known to break many systems. |
| 14 |
|
| 15 |
The developer tested the package and had others test it and it worked |
| 16 |
for them, so he committed it to the ~arch tree, which was the correct |
| 17 |
thing for him to do. |
| 18 |
|
| 19 |
> Having in mind state of the matter in_real_world, I really don't think |
| 20 |
> that having such things at least temporarily masked ( not to mention |
| 21 |
> DOCUMENTED!) is really not overdoing it. |
| 22 |
|
| 23 |
Technically, there is nothing to document except possibly warning |
| 24 |
against changing the oldnet use flag. But, again, if you are using |
| 25 |
~arch packages you should know how to recover. |
| 26 |
|
| 27 |
The openrc guide is at |
| 28 |
http://www.gentoo.org/doc/en/openrc-migration.xml, and it still |
| 29 |
documents the correct way to upgrade to openrc if you did not switch to |
| 30 |
the new network scripts. |
| 31 |
|
| 32 |
> As it was done, it presented me with nasty surprise. Machine has gotten |
| 33 |
> through upgrade world just fine and only after reboot it couldn't start |
| 34 |
> network interfaces. Manual restart croaked with some error about python |
| 35 |
> not being able to find some function. |
| 36 |
|
| 37 |
That doesn't sound like an openrc issue; openrc does not have anything |
| 38 |
to do with python as far as I know. |
| 39 |
|
| 40 |
I would be curious what other packages were involved in the update? |
| 41 |
What did you do to get the system up and running again? |
| 42 |
|
| 43 |
> It felt exactly like a few last times when my ext4 decided to lose a few |
| 44 |
> hundred essential system files. There was nothing to suggest openrc. |
| 45 |
> After I lost some time reemerging system files and sifting through |
| 46 |
> ebuilds, packages and scripts, that casual message here about new openrc |
| 47 |
> hit me purely by chance, otherwise I would be in for much more pain. |
| 48 |
> After I got system running again, I couldn't find anywhere anything at |
| 49 |
> all about any substantial change in openrc. |
| 50 |
> Not on bugzilla, not on openrc home page nor anywhere else. |
| 51 |
|
| 52 |
That's because there wasn't one, and because ~arch is not considered |
| 53 |
stable anyway. ~arch is where things go so that we can get them |
| 54 |
tested, after we test them ourselves, before they move to stable. And, |
| 55 |
as was said above, if you are running ~arch and things break, you are |
| 56 |
expected to know how to recover. |
| 57 |
|
| 58 |
When you file the bug, please give us all of the details about what you |
| 59 |
did, what was upgraded, the exact error message you got, etc. |
| 60 |
|
| 61 |
-- |
| 62 |
William Hubbs |
| 63 |
gentoo accessibility team lead |
| 64 |
williamh@g.o |
Archives