Layman currently generates a make.conf file (by default /var/lib/layman/make.conf), which can be included in /etc/portage/make.conf using source command. Layman-generated make.conf file sets only PORTDIR_OVERLAY variable. This behavior is incompatible with the plan of deprecation of PORTDIR and PORTDIR_OVERLAY in /etc/portage/make.conf in favor of /etc/portage/repos.conf. Possible solutions: - Make Portage support an @include command in /etc/portage/repos.conf and make Layman generate a file (with repos.conf-compatible syntax), which could be included by users in their /etc/portage/repos.conf using @include command. - Make Portage handle updating etc. of repositories so that Layman is no longer needed.
Another possible solution: - Make Portage support a variable (in environment and make.conf), which would specify paths of additional repos.conf-like files, and make Layman generate a file (with repos.conf-compatible syntax), which could be enabled by users by appropriately setting that variable in make.conf.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #0) > - Make Portage support an @include command in /etc/portage/repos.conf and > make Layman generate a file (with repos.conf-compatible syntax), which could > be included by users in their /etc/portage/repos.conf using @include How about if we add a way to reference layman's installed.xml file in repos.conf? That way, portage will be able to work with layman's existing configuration format.
Zac, it would be easy to change layman to produce a ConfigParser type file with installed overlays. It can live in the same location as the current /var/layman/make.conf or anywhere else. So that itself is not an issue. Layman already uses ConfigParser for it's own config file. There needs to be an official announcement that tools should move to the new format. As it stands, even portage's documents on repos.conf say to not use it. It will not even be an issue for layman to do dual format for an interim period. There are more critical tools that will not be as easy to convert. I still purport that portage should designate a directory to contain main tree and any installed overlays, even if the overlay is a symlink to an alternate location. Portage would scan the directory on loading and automatically add any valid repos it finds. Problem solved without editing/modifying any configs. repos.conf would then be used for more fine grained control, alternate installations, etc.. I've added that type of functioning to layman, for adding overlay .xml definitions not in repositories.xml or manually editing layman.cfg. It works great. Simply download the xml definition to it's own aptly-named-file.xml, on the next fetch, it's definition is added to the available overlays. As I've demonstrated in the past, it is not hard to embed layman's api use into portage for normal sync operations. In fact layman could be easily leveraged to do almost any kind of file/repo operations, including live ebuilds. Once I have some other more pressing coding tasks completed, I'll return to the python 3 porting/compatibility changes needed. After that, I would consider it ready to include layman's api use in portage. If layman's api is not importable, then the user likely does not have any layman installed overlays, so will need to manually control repos.conf for overlays they may have installed.
Please do not use xml files for portage configuration: I do not want to include an xml parser into eix. May I suggest to make /etc/portage/repos.conf a directory like /etc/portage/package.* In this way layman could just drop a file (or manage even in directory) in that directory. (eix currently also supports a "source" directive in /etc/portage/repos.conf, but this may be hard to do in python).
(In reply to Martin Väth from comment #4) > May I suggest to make /etc/portage/repos.conf a directory like > /etc/portage/package.* This is supported in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f1181281ba1be9181fa65238f91661625a1432bd
This is fixed in 2.1.12.11 and 2.2.0_alpha186.
