Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 474588 - sys-apps/portage: support repos.conf directory for app-portage/layman interaction
Summary: sys-apps/portage: support repos.conf directory for app-portage/layman interac...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Configuration (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Portage team
Depends on:
Blocks: 240187 472632
  Show dependency tree
Reported: 2013-06-24 10:19 UTC by Arfrever Frehtes Taifersar Arahesis
Modified: 2013-06-29 04:52 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Arfrever Frehtes Taifersar Arahesis 2013-06-24 10:19:12 UTC
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
Comment 1 Arfrever Frehtes Taifersar Arahesis 2013-06-24 17:55:27 UTC
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.
Comment 2 Zac Medico gentoo-dev 2013-06-24 18:12:54 UTC
(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.
Comment 3 Brian Dolbec gentoo-dev 2013-06-24 19:11:56 UTC
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.
Comment 4 Martin Väth 2013-06-27 16:44:43 UTC
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

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).
Comment 5 Zac Medico gentoo-dev 2013-06-28 01:56:44 UTC
(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:;a=commit;h=f1181281ba1be9181fa65238f91661625a1432bd
Comment 6 Zac Medico gentoo-dev 2013-06-29 04:52:02 UTC
This is fixed in and 2.2.0_alpha186.