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

[Jason Stubbs]

On Saturday 05 November 2005 10:39, Brian wrote:
> On Sat, 2005-05-11 at 01:55 +0900, Jason Stubbs wrote:
> > On Friday 04 November 2005 22:33, Marius Mauch wrote:
> > > Ciaran McCreesh wrote:
> > > > On Thu, 03 Nov 2005 23:14:20 -0800 Brian <dol-sen@×××××.net> wrote:
> > > > | emerge -pv <package>
> > > > |
> > > > | would actually continue listing (modified normal)after finding a
> > > > | dependency is masked rather than stop on, and report only, the
> > > > | first one.  The masked packages would need to be marked as such
> > > > | [hard masked, keyword masked], possibly shown grouped in blocks
> > > > | [KEYWORD, HARD MASKED, STABLE].
> > > >
> > > > Problem is, once you hit one bad dependency, you can't carry on and
> > > > guarantee what the rest of the dep tree is going to be. Example:
> > > >
> > > > emerge -pv foo
> > > >
> > > > foo DEPENDs upon bar and baz
> > > > bar DEPENDS upon fnord, and is MASKED
> > > > baz DEPENDs upon || ( gerbil fnord )
> > >
> > > Well, that and other semantic issues (what to do with multiple
> > > candidates for example?).
> >
> > 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.

> > Either way, while there are bugs such as error messages being truncated,
> > requests such as "allow me to break my system easier" are truly far from
> > my mind. Of course, supplied patches will always be reviewed.
>
> 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
-- 
gentoo-portage-dev@g.o mailing list