| 1 |
On Sat, 14 Dec 2013 15:57:04 -0600 |
| 2 |
William Hubbs <williamh@g.o> wrote: |
| 3 |
|
| 4 |
> On Sat, Dec 14, 2013 at 08:47:01PM +0000, Jorge Manuel B. S. Vicetto |
| 5 |
> wrote: |
| 6 |
> > OK, I see what you mean. |
| 7 |
> > To be clear, I'm not ready to have a stage3 without netifrc. If / |
| 8 |
> > when we update catalyst so that the new stage3 is the sum of |
| 9 |
> > @system and additional packages, we can move netifrc to that list. |
| 10 |
> |
| 11 |
> Actually I'm not even sure how necessary that kind of update is. |
| 12 |
> |
| 13 |
> I didn't quite follow what the reasoning against my second proposal |
| 14 |
> was. |
| 15 |
> |
| 16 |
> Once openrc-0.12.4 is stable everywhere it is going to go stable, I |
| 17 |
> want to add virtual/network-manager to the tree. This would contain a |
| 18 |
> list of network manager providers. |
| 19 |
> |
| 20 |
> I think adding it to the tree is good, because we have other virtuals |
| 21 |
> for multiple packages that perform the same function -- |
| 22 |
> virtual/logger, virtual/mta, etc. |
| 23 |
> |
| 24 |
> Once that is done, we could easily add it to @system then I would drop |
| 25 |
> the netifrc use flag. That would take care of the situation if netifrc |
| 26 |
> was the default provider. |
| 27 |
> |
| 28 |
> Then, if you decide to add the function you are talking about to |
| 29 |
> catalyst, we could look into dropping virtual/network-manager from |
| 30 |
> @system. |
| 31 |
> |
| 32 |
> I'll attach the ebuild below so everyone sees it. |
| 33 |
> |
| 34 |
> William |
| 35 |
> |
| 36 |
|
| 37 |
IMHO this virtual shouldn't be added. It would be a pure meta package |
| 38 |
for the user. That case is not directly comparable with virtual/mta: |
| 39 |
We've got this for other packages to depend on it, at least that is my |
| 40 |
understanding. In a case like this, a handbook entry should suffice. |
| 41 |
|
| 42 |
|
| 43 |
Luis Ressel |
Archives