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