Re: [gentoo-portage-dev] emerge -pv and masked dependencies

[Brian]

On Sat, 2005-05-11 at 13:48 +0900, Jason Stubbs wrote:
> On Saturday 05 November 2005 10:39, Brian wrote:
> > >
> > > Multiple candidates is the most worrying for me as well. a-1.1 is masked
> > > and requires >=b-1.0. b has 1.0 and 1.1 both of which are masked. b-1.0
> > > requires c-1.0 while b-1.1 requires c-1.1. c-1.1 masked but c-1.0 isn't.
> > > Should the above "keep going" just grab the highest *masked* version at
> > > each stage?
> >
> > Isn't that what users end up with after adding each package to
> > package.keywords then emerge-pv <package> again, and again...
> > unless they do detailed research for each failed dep.  I know I never
> > looked that close at the packages each time it happened as long as it
> > wasn't hard masked.
>
> So whatever atom it was that has all packages masked should be unmasked? That
> seems like it would work. The next problem is the four/five types of masking
> currently in use; ~arch, -arch, arch not specified, package.mask and
> profile's packages.

<snip>
> >
> > Well, I don't know that I could supply patches to portage. I have enough
> > to keep track of in porthole let alone learn the intricacies of package
> > management.  It sounds like this is something easier done in porthole
> > where we can display all relevant packages in a dialog with checkboxes
> > for package selection and possibly an adjustable search depth.  That way
> > package research could be done in porthole's main window to help decide
> > whether they wish to proceed and or which version to select.
>
> Actually, it would take a fair bit of work on the portage side. At the moment,
> there's no existing function to figure out how a package is masked, nor is
> there an easy way change the configuration after it is read in from the
> config files. Unless you plan to parsing the text returns from
> getmaskingstatus() and manually inserting data into this and that config,
> you'll need to patch portage anyway...
>
> --
> Jason Stubbs

For what I had in mind I should not have to patch portage.  I would be
using porthole's dependency list code and pick out the unsatisfied
masked deps and display them in a dialog for approval.  After they have
been package.whatever'd, then check with an emerge -pv for a final
check.  Just in case porthole's dependency calc's did not get all of
them correct.  But I have not run across one yet since Tommy reworked
that code. 

One possibility to add that functionality to portage would be to invoke
a standalone dep-scan utility rather than just print the standard
failure message.  That would require minimal change to working stable
portage code and add that feature.  The next step is for me to come up
with some porthole code to test my theory on.  If it is successful a
standalone utility should be able to be developed from it.

-- 
Brian <dol-sen@×××××.net>

-- 
gentoo-portage-dev@g.o mailing list