pkgcore
Add a way to disable /etc/portage/make.profile check
My /etc/portage/make.profile is a directory containing a parent file that points to the right profile dir and a use.stable.mask that unmasks masks which allows me to test masked packages. I get to do a lot of overrides as well besides that. Please add a way to disable checking it (or maybe add a way to also include it when doing recursive loading of profile data if it does).
This is the error message I'm getting after running pkgcheck scan:
pkgcheck show: error: invalid symlink: '/etc/portage/make.profile'
First of all, as a "fast" fix, you can use /etc/portage/profile/ dir to define your profile overrides. For example, on my machine, I have a file at /etc/portage/profile/use.force, and I think you can also define a /etc/portage/profile/use.stable.mask there. Then I think you can have make.profile back as a symlink to a "real" profile.
About support not-symlink /etc/portage/make.profile, I will check if this is allowed by PMS, and if we desire to support such case. Just FYI, the fact portage supports it doesn't promise this is defined by PMS, so I will check it. But I hope my "fast fix" will help you (I also think this is the intended way to make such modifications).
Aforementioned use case with use.stable.mask is not too useful, but there are other more useful reasons to have /etc/portage/make.profile as directory with /etc/portage/make.profile/parent regular file:
- Creation of profile being custom combination of pre-existing profiles (described in https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/profiles.desc)
https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/profiles.desc contains e.g.:
amd64 default/linux/amd64/17.1 stable
amd64 default/linux/amd64/17.1/selinux stable
amd64 default/linux/amd64/17.1/hardened stable
amd64 default/linux/amd64/17.1/hardened/selinux stable
amd64 default/linux/amd64/17.1/desktop stable
amd64 default/linux/amd64/17.1/desktop/gnome stable
amd64 default/linux/amd64/17.1/desktop/gnome/systemd stable
amd64 default/linux/amd64/17.1/desktop/plasma stable
amd64 default/linux/amd64/17.1/desktop/plasma/systemd stable
amd64 default/linux/amd64/17.1/desktop/systemd stable
amd64 default/linux/amd64/17.1/developer exp
amd64 default/linux/amd64/17.1/no-multilib stable
amd64 default/linux/amd64/17.1/no-multilib/hardened stable
amd64 default/linux/amd64/17.1/no-multilib/hardened/selinux stable
amd64 default/linux/amd64/17.1/no-multilib/systemd dev
amd64 default/linux/amd64/17.1/no-multilib/systemd/selinux exp
amd64 default/linux/amd64/17.1/systemd stable
amd64 default/linux/amd64/17.1/systemd/selinux exp
amd64 default/linux/amd64/17.1/clang exp
amd64 default/linux/amd64/17.1/systemd/clang exp
Many valid combinations currently do not exist in gentoo.git's profiles, e.g. profiles which are plasma+selinux or gnome+plasma or gnome+plasma+systemd or plasma+hardened+selinux.
Users who want plasma+selinux can have in their /etc/portage/make.profile/parent:
gentoo:default/linux/amd64/17.1/desktop
gentoo:targets/desktop/plasma
gentoo:features/selinux
Users who want gnome+plasma can have in their /etc/portage/make.profile/parent:
gentoo:default/linux/amd64/17.1/desktop
gentoo:targets/desktop/gnome
gentoo:targets/desktop/plasma
Users who want gnome+plasma+systemd can have in their /etc/portage/make.profile/parent:
gentoo:default/linux/amd64/17.1/desktop
gentoo:targets/desktop/gnome/systemd
gentoo:targets/desktop/plasma
Users who want plasma+hardened+selinux can have in their /etc/portage/make.profile/parent:
gentoo:default/linux/amd64/17.1/desktop
gentoo:targets/desktop/plasma
gentoo:features/hardened/amd64
gentoo:features/selinux
PMS doesnt touch this issue, which I interpret to be due to choosing your profile falling under package manager configuration.
"This document does not specify any user or package manager configuration information."
- 1.1 Aims and Motivation
So in this case falling back to portages documented behavior would be reasonable to a certain extent.
/etc/portage/make.profile/ or /etc/make.profile/ This is usually just a symlink to the correct profile in /var/db/repos/gentoo/profiles/. ... If you need a custom profile, then you should make your own make.profile directory and populate it. However, if you just wish to override some settings, use /etc/portage/profile/ (it supports all of the same file types that make.profile does, except parent). ... If both /etc/portage/make.profile/ and /etc/make.profile/ exist, then /etc/portage/make.profile/ will be preferred.
- https://github.com/gentoo/portage/blob/master/man/portage.5#L219..231 with my emphasis and light editing
(Not too sure about the relevance of also supporting /etc/make.profile as its a backwards compatability measure and is referred to as deprecated in portage internally. Ignoring /etc/make.profile would follow precedent of ignoring /etc/make.conf in pkgcore).
This error is coming from pkgcore which makes the assumption that make.profile can only be a symlink, which is incorrect as pkgcore is supposed to convert portages configuration files and would therefore abide by portages documented behavior unless documented otherwise.
In any case this issue should be addressed in pkgcore and the difference in behavior should be documented if left in.
(Not too sure about the relevance of also supporting /etc/make.profile as its a backwards compatability measure and is referred to as deprecated in portage internally. Ignoring /etc/make.profile would follow precedent of ignoring /etc/make.conf in pkgcore).
This error is coming from pkgcore which makes the assumption that make.profile can only be a symlink, which is incorrect as pkgcore is supposed to convert portages configuration files and would therefore abide by portages documented behavior unless documented otherwise.
In any case this issue should be addressed in pkgcore and the difference in behavior should be documented if left in.
I'm sorry for not being clear enough with tagging this issue as "bug" - I got enough explanations about PMS and Portage conf, and I agreed that this is a bug and not "wont fix". I do want to fix it!
But, the issue is that currently the code at pkgcore not only checks for make.profile being a symlink, but based on this assumption it does something else (find other places of profiles? I really don't know). Please understand I'm new maintainer of this whole stack, and I still don't have good understanding of the whole stack. Also because of my availability time I can't guarantee any ETA - I'm trying my best, but this might take some time.
Could you (those using make.profile as dir and not symlink) test if fixed by https://github.com/pkgcore/pkgcore/pull/390 applied to pkgcore?
Installed pkgcore-9999 with your make_profile_custom branch and it worked for me.