On Thu, 2014-01-09 at 19:46 +0100, Sebastian Luther wrote: > The layout makes sense. Except the problems I see with where the > modules are installed (see later). > > Not sure about module_spec yet. > > > [...] > >
The module_spec is a means to make available to the operational manager what the module supplies and any options it provides. The second thing it does is not import the files and modules it supplies. This reduces the memory requirements by not loading modules, files that are not needed. It also speeds up run time as a result. > > <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. That is to be determined. It doesn't matter where to the plugin manager. It needs a path to the plug-in directory on initialization. It does not need to be in a subdirectory where it is located. > 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). > The plug-in must be able to work with all supported python versions in one form or another. In esearch, it supports python 3, but layman does not (yet), so when you use the -l switch to sync layman overlays as well as the main tree. It first tries to import the layman modules, upon failure it falls back to calling layman using a subprocess call. Just like portage currently calls rsync and git in a subprocess now. see working code: https://github.com/fuzzyray/esearch/blob/master/esearch/sync.py layman_sync() line # 149 If a proposed module is to be added to the tree, it should be capable of working in all configurations a user may have withing portage's capability. If not, if it isn't shipped by and with portage, then it is a user issue. Not ours. In such a case we (the portage-tools team) would insist on ewarns in the ebuild stating such constraints, etc.. > > 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 > > > >
signature.asc
Description: This is a digitally signed message part
