Summary: | Feature Request to make ":" a replacement for ${PORTDIR}/profiles | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Martin Scholz <golodhrim> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | golodhrim, grzegorz, staff, tools-portage |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 240187, 428678, 409383 | ||
Attachments: |
support colon in profile parent with profile-formats = portage-2
Profile parent repo: references Profile parent repo: references |
Description
Martin Scholz
2012-05-07 03:15:25 UTC
This should be easy to do nowadays, since the recently added profile-formats support makes LocationsManager aware of repo paths. What about inventing a syntax that allows using repository names? Once you allow to reference $PORTDIR, people are going to ask for reference to some overlay. This thing needs an EAPI change as the parents file is under EAPI control. IIRC there is already a bug asking for something like that. I would be fine with the ability to specify repo names. Having a shorthand to mean "relative to PORTDIR/profiles" (ie. ":") is also a good thing. (In reply to comment #2) > This thing needs an EAPI change as the parents file is under EAPI control. We are already using "profile-formats = portage-1" in metadata/layout.conf to indicate that directories can be used in place of files. So, we could enable this extension with "profile-formats = portage-2" or something like that. Created attachment 311391 [details, diff]
support colon in profile parent with profile-formats = portage-2
Feedback from irc: <drobbins> zmedico: that's the tricky thing - we are going to use the syntax in /etc/portage/make.profile/parent <drobbins> zmedico: as an easy way to link into the portdir <zmedico> drobbins: hmm, so we need to somehow know PORTDIR beforehand? that's tricky <drobbins> zmedico: yeah <drobbins> zmedico: now, that's why I had another kewl patch that used /etc/portage/portdir to define the portdir <drobbins> zmedico: so /etc/make.conf would not need to be parsed first. <drobbins> zmedico: this is the chicken and egg part. <zmedico> drobbins: would be simpler if we make if funtoo: <zmedico> that way, PORTDIR is irrelevant <zmedico> I mean, specify repo name in the parent file <drobbins> so we would have <repo-name>:asdlfkasd <drobbins> or similar syntax (I'm flexible) <zmedico> right <drobbins> that would be perfectly fine. Don't stop any work on this, but I'm adding tools-portage to the CC, because there is a strong possibility that this will break things in gentoolkit. Created attachment 311927 [details, diff]
Profile parent repo: references
This applies to 2.2.0_alpha105 or 2.1.10.60.
In testing the patch with Portage 2.1.10.60, except for 'euse' everything in gentoolkit appears to be working fine. I did not encounter any other portage or gentoolkit errors in the testing. (In reply to comment #8) > Created attachment 311927 [details, diff] [details, diff] > Profile parent repo: references > > This applies to 2.2.0_alpha105 or 2.1.10.60. There's a bug in this patch related to the RepoConfig.portage1_profiles attribute, which prevents the config-file-as-directory extension from working correctly for portage-2. As a workaround, setting "profile-formats = portage-1 portage-2" should give the desired result. I'll rebase the patch on top of the following related commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f39ac7dc706544d1f36392c7def6da0b9b6bebcf Created attachment 312071 [details, diff] Profile parent repo: references This applies to 2.2.0_alpha107 or 2.1.10.62, and fixes the issue discussed in comment #10. last attached diff works with portage-2 only enabled This is in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6dd44c1b5f13c3628bc2e093fdf4b1ade4028b63 This is fixed in 2.1.10.65 and 2.2.0_alpha110. *** Bug 331683 has been marked as a duplicate of this bug. *** |