| Summary: | [Future EAPI] parent files should support "namespaces" | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Eduard Bachmakov <e.bachmakov> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | esigra |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
1. PMS doesn't cover multi-repo support at all. 2. There's no requirement that profiles must reside inside a repository at all. (In reply to Michał Górny from comment #1) > 1. PMS doesn't cover multi-repo support at all. It should but I guess that's a discussion for another time. Aside from that, it wouldn't have to be multi-repo. If there is a notion for THE repo, that's all you need (see below). > 2. There's no requirement that profiles must reside inside a repository at > all. That's fine and that's exactly why then there has to be a system/machine-agnostic way to refer to a profile directory that is part of a/the tree since it's mandated that a tree is to have one. Since we have "repo_name" it is given that a repo has a name. So let's be able to refer to it by name rather than by location. I don't like this: it doesn't scale to "more than one overlay wants to do stuff with profiles". It's just a quick workaround that avoids fixing the problem properly. @Ciaran: That's not necessarily the problem in this case. Like Michal said, profiles must not be connected to repositories. While "more than one overlay wants to do stuff with profiles" is a real issue to be solved it is what we're trying to accomplish in this bugreport. It merely covers situations like "an out of repo profile wants to refer to repo by name instead of (hardcoded) path" I'm contesting the whole "overlays providing profiles" idea. It hasn't been thought out, and this one change won't make it work. That's certainly a debatable topic. If I was proposing a specification on how and if overlays with profiles would work, we could take this further.
However, that's a strawman and not what I'm trying to accomplish here. The question is not "overlays providing profiles".
Consider the profile
default/linux/amd64/13.0/desktop/gnome/systemd
It has the parent file of
..
../../../../../../../targets/systemd
Considering the repo_name is `gentoo` this change would allow to write
..
gentoo:targets/systemd
Aside from the added clarity it also prevents breaking if a profile where to e.g. move deeper
ONCE the whole overlay issue would be figured out we COULD POTENTIALLY utilize this for that.
For now we can just have a out of repo/overlay profiles refer to profiles even if either or both are e.g. random NFS mounts.
But we could solve the issue you describe without reference to repository names, by defining a ${profiles} variable or similar. This would avoid giving the impression that it has something to do with overlays.
(In reply to Eduard Bachmakov from comment #0) > Since portage already supports namespaces (please excuse me if that's the > wrong terminology) such as > > gentoo:default/linux/amd64/13.0/desktop , > > [...] Sorry, but where does Portage support such a syntax? (The eselect profile module can display profiles with a repository prefix. This was added on users' request in bug 265264, but it isn't a package manager feature.) @Ciaran: where would that variable be set? @Ulrich: Not sure how to answer "where" but it does work. Look at the parent files in https://github.com/eduarrrd/eduarrrd-gentoo/tree/master/profiles I just symlink /etc/portage/make.profile -> /var/lib/layman/eduarrrd/profiles/jupiter and the inheritance works out just right. I didn't know eselect knew of profiles in overlays because it doesn't show them for me ... maybe that's why. Portage/emerge works just fine though. (In reply to Ulrich Müller from comment #8) > Sorry, but where does Portage support such a syntax? > > (The eselect profile module can display profiles with a repository prefix. > This was added on users' request in bug 265264, but it isn't a package > manager feature.) This support was added to portage via the "portage-2" profile-format (search for "portage-2" under the /usr/portage/metadata section of the portage manpage). |
Section 5.2.1 of PMS states "Each line must contain a relative path to another profile which will be considered as one of this profile’s parents." Since portage already supports namespaces (please excuse me if that's the wrong terminology) such as gentoo:default/linux/amd64/13.0/desktop , additing this information to the PMS would allow other package managers to sync to this behavior. The purpose is to be able to locate a parent profile even if this profile's location isn't known. Example: A profile is in /home/user/projects/profile and is synced to another machine's /etc/portage/make.profile. Relative addressing would break. An alternative idea would be to allow absolute pathnames but that makes other assumptions which may not hold in all cases/forever.