Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 889640

Summary: [Future EAPI] profiles/parent: support <repo>: prefix
Product: Gentoo Hosted Projects Reporter: Arthur Zamarin <arthurzam>
Component: PMS/EAPIAssignee: PMS/EAPI <pms>
Status: CONFIRMED ---    
Severity: enhancement CC: esigra, gentoo, sam
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 174380, 884879    

Description Arthur Zamarin archtester Gentoo Infrastructure gentoo-dev Security 2023-01-04 05:33:31 UTC
Currently PMS allows only paths in the "parent" file for profile. This could be a relative one (which is used between profiles in ::gentoo as an example) or absolute one (for example for user configured profiles).

But this makes it hard for overlays to create a profile which depends on another overlay's profile as parent.

In portage (look at `man 5 portage`), you can use the <repo>:<path> syntax:

> If layout.conf  is  new enough, you can also use the <repo>:<path> syntax.
> The <repo> is the same string as is stored in the repo_name file (or omitted
> to refer to the current repo), and <path> is a subdir starting at profiles/.


Some things mentioned by @ulm in IRC channel:

> would <repo> be allowed to have any value? or only master repositories of
> the current repo?

I believe we can limit this when used for profiles of repositories, as this is a
good idea, as we need to declare the dependency of the repo for this profile to
even work.

But for user profiles (/etc/portage/make.profile used as a directory with a parent file, not as a symlink to a profile in a repo) I think we allow any repo name that is defined in /etc/portage/repos.conf.
For PMS I don't know if the above text for user profiles is needed, but I added my thoughts.

> how do we distinguish file name foo:bar from repo:profile?
> restricting profile names to chars [A-Za-z0-9+_.-] would avoid the problem
> (and hopefully won't restrict anything in practice)

While I think restricting any directory name or path name to use normal chars (I think : is quite problematic, for example used for $PATH separation), we can also do it another way:
If : appears in path, it is always a <repo>:, and for usage with a path containing :, just declare it in syntax of <repo>:<path> (AKA 2 appearances of : in the line). Any normal path can be defined using <repo>:<path> so this is acceptable (for such a rare possible situation).