1 |
Am 09.01.2014 18:33, schrieb Brian Dolbec: |
2 |
> <introduction> |
3 |
> |
4 |
> <history of the plugin system> |
5 |
|
6 |
I fully agree with idea behind the plugin system. That is, to keep |
7 |
things that are separate, separate. It probably wouldn't have occurred |
8 |
to me to implement it that way (i.e. with auto-detection) but that's |
9 |
just fine. |
10 |
|
11 |
I don't see a problem with reusing that system here. |
12 |
|
13 |
> I have started a Proposals sub-page under the Portage project page |
14 |
> in the wiki. It has a link to a diagram I made showing how the |
15 |
> plug-in system is laid out. This thread will be used to discuss |
16 |
> the proposal and the details needed for the module_spec dictionary |
17 |
> that is used to provide the manager with the details of what a |
18 |
> module provides, options, etc.. |
19 |
> |
20 |
|
21 |
The layout makes sense. Except the problems I see with where the |
22 |
modules are installed (see later). |
23 |
|
24 |
Not sure about module_spec yet. |
25 |
|
26 |
> [...] |
27 |
> |
28 |
> <stuff about ebuilds installing plugins> |
29 |
> |
30 |
While I see a valid use case here (especially with your squashfs |
31 |
example), I wonder how that is supposed to work. |
32 |
|
33 |
1) Where should the ebuild install the plugin? |
34 |
2) How does portage find those plugins. |
35 |
3) How does portage's behavior to run with the currently selected |
36 |
python version, mix with the fact that ebuilds usually install only |
37 |
for some set of python versions? (especially python 2 vs 3). |
38 |
|
39 |
> This system would also make it possible to modify emerge-s cli to |
40 |
> accept target repos to sync. and not any others also installed. |
41 |
> Similarly to "layman -s some-overlay", "emerge --sync |
42 |
> some-overlay" |
43 |
|
44 |
"emerge --sync some-overlay" already works. |
45 |
|
46 |
|
47 |
> P.S. sorry for such a long email |
48 |
> |