| 1 |
On Thu, 2014-01-09 at 19:46 +0100, Sebastian Luther wrote: |
| 2 |
|
| 3 |
> The layout makes sense. Except the problems I see with where the |
| 4 |
> modules are installed (see later). |
| 5 |
> |
| 6 |
> Not sure about module_spec yet. |
| 7 |
> |
| 8 |
> > [...] |
| 9 |
> > |
| 10 |
|
| 11 |
The module_spec is a means to make available to the operational manager |
| 12 |
what the module supplies and any options it provides. |
| 13 |
|
| 14 |
The second thing it does is not import the files and modules it |
| 15 |
supplies. This reduces the memory requirements by not loading modules, |
| 16 |
files that are not needed. It also speeds up run time as a result. |
| 17 |
|
| 18 |
> > <stuff about ebuilds installing plugins> |
| 19 |
> > |
| 20 |
> While I see a valid use case here (especially with your squashfs |
| 21 |
> example), I wonder how that is supposed to work. |
| 22 |
> |
| 23 |
> 1) Where should the ebuild install the plugin? |
| 24 |
> 2) How does portage find those plugins. |
| 25 |
|
| 26 |
That is to be determined. It doesn't matter where to the plugin |
| 27 |
manager. It needs a path to the plug-in directory on initialization. |
| 28 |
It does not need to be in a subdirectory where it is located. |
| 29 |
|
| 30 |
|
| 31 |
> 3) How does portage's behavior to run with the currently selected |
| 32 |
> python version, mix with the fact that ebuilds usually install only |
| 33 |
> for some set of python versions? (especially python 2 vs 3). |
| 34 |
> |
| 35 |
|
| 36 |
The plug-in must be able to work with all supported python versions in |
| 37 |
one form or another. |
| 38 |
|
| 39 |
In esearch, it supports python 3, but layman does not (yet), so when you |
| 40 |
use the -l switch to sync layman overlays as well as the main tree. It |
| 41 |
first tries to import the layman modules, upon failure it falls back to |
| 42 |
calling layman using a subprocess call. Just like portage currently |
| 43 |
calls rsync and git in a subprocess now. |
| 44 |
|
| 45 |
see working code: |
| 46 |
https://github.com/fuzzyray/esearch/blob/master/esearch/sync.py |
| 47 |
layman_sync() line # 149 |
| 48 |
|
| 49 |
|
| 50 |
If a proposed module is to be added to the tree, it should be capable of |
| 51 |
working in all configurations a user may have withing portage's |
| 52 |
capability. If not, if it isn't shipped by and with portage, then it is |
| 53 |
a user issue. Not ours. In such a case we (the portage-tools team) |
| 54 |
would insist on ewarns in the ebuild stating such constraints, etc.. |
| 55 |
|
| 56 |
> > This system would also make it possible to modify emerge-s cli to |
| 57 |
> > accept target repos to sync. and not any others also installed. |
| 58 |
> > Similarly to "layman -s some-overlay", "emerge --sync |
| 59 |
> > some-overlay" |
| 60 |
> |
| 61 |
> "emerge --sync some-overlay" already works. |
| 62 |
> |
| 63 |
> |
| 64 |
> > P.S. sorry for such a long email |
| 65 |
> > |
| 66 |
> |
| 67 |
> |
Archives