Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 341411 - sys-apps/portage-2.2_rc97: only the /etc/portage/package.mask and package.mask in user's profile are global
Summary: sys-apps/portage-2.2_rc97: only the /etc/portage/package.mask and package.mas...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-17 06:06 UTC by Oschtan
Modified: 2011-01-13 05:08 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oschtan 2010-10-17 06:06:22 UTC
Mask ebuild in package.mask any overlay only if the ebuild belongs to the same overlay, in which package.mask. Thus, to mask the ebuild from the root of the tree portage "gentoo" is possible only in the global file /etc/portage/package.mask. This in turn makes it difficult, for example, the administrative problems, when an administrator to create a certain number of such systems have to instead create their own overlay only ever exported from the system into the global files from /etc/portage/package .*

Reproducible: Always

Steps to Reproduce:
Comment 1 Zac Medico gentoo-dev 2010-10-17 06:55:34 UTC
As shown in bug #336692, QA team seems to have taken a rather strict stance on what's allowed in the official profiles. However, I suppose that we could add a FEATURES setting (or something similar) that would give more control to the profiles. It would be possible for you to enable this FEATURES setting from within your profile.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-10-17 07:25:47 UTC
We could add an another level of configuration (for 'shared' configs). Or simply replace package.mask file with a directory, with a single file being shared (i.e. over VCS).
Comment 3 Sebastian Luther (few) 2010-10-17 16:55:13 UTC
I corrected the summary to reflect the fact that the package.mask entries in the user's profile are global too.

(In reply to comment #0)
>This in turn makes it difficult, for example, the
> administrative problems, when an administrator to create a certain number of
> such systems have to instead create their own overlay only ever exported from
> the system into the global files from /etc/portage/package .*
>

Could you please explain your current work flow a bit more? Specifically:
Where do you put your custom settings and how do you distribute them to the client systems?
What kind of custom settings do you have there / what do you achieve with them?
Comment 4 Oschtan 2010-10-17 17:27:08 UTC
Configured only one parent system. What has to adjust the fit /usr/local/portage/profiles. This overlay applies to rsync on all child systems and their configuration is reduced to upgrade.
Settings relating to versions of various packages (masked packages, from the main tree and overlays), including the management of masking packages such cases, when the installation of other (non-version, namely the package when you select a virtual/*). For example, virtual/cdrtool: either app-cdr/cdrtools, or app-cdr/cdrkit.
Including cases with sys-apps/man (system profile), when he took masked in connection with the removal of Russian localization and the need to install sys-apps/man-db.
Very inconvenient to handle such administrative functions, write them on paper or by hand or permanently importing a folder /etc/portage/
Comment 5 Sebastian Luther (few) 2010-10-17 17:38:59 UTC
Thank you for the clarification.

The old way of treating overlay settings as global settings has the problem that adding a new overlay causes side effects for other overlays. But it shouldn't do any more than adding additional ebuilds. I see how this was useful for you though.

What about moving your settings to /etc/portage/profile/?
Comment 6 Oschtan 2010-10-17 18:15:49 UTC
The new realities require new solutions. Even the import of settings from /etc/portage yet maternal system can contain additional settings. And here arises the problem of overlapping. Thank you for your comment. Possible softer Manage your profile it would still be more convenient.
Comment 7 Sebastian Luther (few) 2010-10-17 20:08:37 UTC
(In reply to comment #6)
> Possible softer
> Manage your profile it would still be more convenient.
> 

Another possible solution is to create a custom profile and ship this in your overlay. You could make it inherit existing profiles using the 'parent' file. For the latter you would need to ensure that $PORTDIR is the same on all your clients (at least relative to your repository).
Comment 8 Zac Medico gentoo-dev 2010-10-19 04:40:53 UTC
(In reply to comment #7)
> Another possible solution is to create a custom profile and ship this in your
> overlay. You could make it inherit existing profiles using the 'parent' file.
> For the latter you would need to ensure that $PORTDIR is the same on all your
> clients (at least relative to your repository).

Bug 331683 requests support for repo names in parent files, so that the paths don't have to be hardcoded like that.