Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 194272 - main package.mask affect overlay ebuilds
Summary: main package.mask affect overlay ebuilds
Status: RESOLVED INVALID
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Repoman (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-30 12:46 UTC by Federico Ferri (RETIRED)
Modified: 2007-10-02 15:23 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 Federico Ferri (RETIRED) gentoo-dev 2007-09-30 12:46:38 UTC
as subject says.

if a package is masked in /usr/portage/profiles/package.mask, repoman doesn't allow to commit (to overlay) ebuilds depending on it, even if the masked package is manually unmasked in /etc/portage/package.unmask

the errors given by repoman are obviously RDEPEND.bad, DEPEND.bad

I think this shouldn't happen, cause I'm using repoman for commit stuff to an overlay, and also the ebuild dependency is in overlay.
Comment 1 SpanKY gentoo-dev 2007-09-30 12:51:33 UTC
sounds to me like repoman is working correctly ... there's also no real way to determine whether you're in "an overlay" or "the official tree"

i'd say use the --force option to repoman and be done
Comment 2 Marius Mauch (RETIRED) gentoo-dev 2007-10-02 10:29:20 UTC
repoman specifically ignores any files in /etc/portage on purpose.
Comment 3 Zac Medico gentoo-dev 2007-10-02 15:23:20 UTC
(In reply to comment #0)
> if a package is masked in /usr/portage/profiles/package.mask, repoman doesn't
> allow to commit (to overlay) ebuilds depending on it, even if the masked
> package is manually unmasked in /etc/portage/package.unmask

As said, /etc/portage is a _local_ config but repoman is doing QA on the _repository_. I think what you really want is repoman to treat the overlay as a separate repository from the main tree, having independent package.mask settings rather than inheriting them. I think it's reasonable for us to support that type of behavior in the future when we have multiple repository support, if not by default then at least as an option.