| 1 |
Am 31.01.2014 06:27, schrieb Brian Dolbec: |
| 2 |
|
| 3 |
> I have updated the Proposal page [2] with more things to do as well as |
| 4 |
> some insights I discovered during the initial porting. |
| 5 |
> |
| 6 |
|
| 7 |
> 6. Determine the method to be able to do concurrent repo syncs |
| 8 |
|
| 9 |
Take a look at the stuff in portage.util.{_async,_eventloop}. It's used |
| 10 |
in various places in emerge if you need an example. |
| 11 |
|
| 12 |
> 18. Modify emerge-webrsync cli to use the new webrsync module |
| 13 |
|
| 14 |
I'd just remove emerge-webrsync and ask the user to use emerge --sync |
| 15 |
instead. |
| 16 |
|
| 17 |
> Next up for discussion is what additional functionality should a module |
| 18 |
> supply? |
| 19 |
> |
| 20 |
> I think it should provide a list or dictionary of the repos.conf |
| 21 |
> variables it needs or uses. I also think that the module should |
| 22 |
> provide a function for validating the conf variables meet some minimum |
| 23 |
> standard/obvious error checking. |
| 24 |
|
| 25 |
Why should it provide that list at all, if it has a function to validate |
| 26 |
its input? The calling code should just check sync-type, select the |
| 27 |
appropriate module and pass everything to it. |
Archives