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 <[EMAIL PROTECTED]> -- gentoo-portage-dev@gentoo.org mailing list
