I will attach an updated ufed script which accepts a couple of parameters to filter the flags one can edit. If you run "ufed -g" it will only show the global use flags If you run "ufed <ebuild>, <ebuild1>, ..." it will look up "equery which <ebuild>" and only allow you to edit the flags that matter to <ebuild>, <ebuild1>, ... If you run "ufed -g <ebuild>, <ebuild1>, ..." it will only allow you to edit the *global* flags that matter to <ebuild>, <ebuild1>, ... My perl skill are not guru level, so my apologies if my changes cause any problems. Reproducible: Always Steps to Reproduce:
Created attachment 68954 [details] Enhanced version of ufed
Sorry, I just realized that, for example, when you run "ufed sun-jdk", make changes, and save it totally destroys all your use flags except the subset that sun-jdk is concerned with. I guess it needs some more work. Perhaps it'll give a head start to an interested person.
Created attachment 68969 [details] Revised, Enhanced version of ufed I've attached a new 'fixed' version of the enhanced ufed script. I believe I have tested it with nearly every combination of parameters, and it works correctly on my box. It now uses a working set of use flags that it resolves with all of the currently set use flags before it saves.
Two more notes, then I promise I'm done. First, since my changes make use of equery. I believe that creates a dependency on the gentoolkit package. Second, there may be some performance enhancements necessary. I've only tested the ebuild filtering with packages with a small list of use flags, whereas some of the loops I've added are nested and would increase polynomially as more flags are involved. Since basically we are just talking about set operations it might be better to do something like what the resolve_flags method does and use hashtables instead of arrays. I also have not tested the filtering with a wide array of ebuilds, so I'm not sure if my regular expressions will scale well. With all of those caveats, I hope my changes can still be of use.
I assume (because of the version number) this is a modified version of ufed 0.36? I'm slowly working on getting ufed 0.40 ready, and I doubt your changes can be applied to what I have now without modifications. For post-0.40, filtering in another form is on my to-do list, and I'd like to try to keep the changes needed for it in the interface code as much as possible, so it will need to be written rather differently. If you would like to use your custom ufed - I assume you would - some notes on the implementation: IUSE may also be set from eclasses, so simply searching for IUSE="..." won't catch all flags. IUSE="flag1"; IUSE="${IUSE} flag2" is also valid and would be misinterpreted. More importantly, it would seriously misbehave in the simple case IUSE="flag1" # flag2 is disabled for now because it assumes IUSE="..." is all that's on the line. It's probably easiest to query portage for the IUSE flags. This would involve writing a short Python program, which basically does the equivalent of emerge --pretend --verbose --nodeps pkgname. Hope that helps somewhat, and sorry I can't really add your changes.
(In reply to comment #5) > It's probably easiest to query portage for the IUSE flags. This would involve > writing a short Python program, which basically does the equivalent of emerge > --pretend --verbose --nodeps pkgname. Just use d.g.o/~genone/scripts/auxget ;)
Thanks for the comments. I know my regexp wasn't robust. It's been a while since I've done Perl and, well, Perl is Perl. I'll look forward to 0.40 and beyond. Filtering would be a cool addition to ufed, because often times I don't want to wade through a list of 100+ use flags. I only want to see the flags that matter to particular packages. Thanks for all your work on ufed.
This is a nice idea, but needs some planning. The filtering for "global" versus "local" USE-flags is discussed in bug 104852 already. But a different build up of the shown USE-flags if a specific package is added on the command line sounds interesting. It is a bit like "equery u <package>" but with editing functionality, right? Well, I guess I go "spying" in gentoolkit how they do it. ;)
This is now work in progress, as it is on my todo list now that the new 0.90_rc1 is out.
Svwn, was this ever addressed in the current 0.92?
What is the status on this?
(In reply to Jonas Stein from comment #11) > What is the status on this? Currently I am working on elogind. ufed is next on my list, but I will not continue until elogind-234 (current systemd stable version) is out. Cautiously I'd say that I'll need another two weeks until elogind-234 will be out. However, I have planned a few upgrades to ufed, and this one is in the top three of my list.
sys-auth/elogind-235.2-r1 is out and the ticket is 5 years in progress/on todo list... It seems to be a more complicate problem. If you got stuck, we are glad to help on IRC #gentoo-dev-help if it is related to gentoo or on perl channels, if it is related to perl.
(In reply to Jonas Stein from comment #13) > sys-auth/elogind-235.2-r1 is out and the ticket is 5 years in progress/on > todo list... > It seems to be a more complicate problem. > If you got stuck, we are glad to help on IRC #gentoo-dev-help if it is > related to gentoo or on perl channels, if it is related to perl. Thanks for the reminder! There is only one problem: Time. For a lot more months than I liked, issues keep popping up in all sorts of projects, demanding what little spare time I have. This means I have to prioritize "major issue" on project "Foo" higher than "nice to have" on ufed. However, I am working on being able to regain at least some control over my spare time. That said, I would be happy if I had time to work on ufed, as there are quite some things to do, and some of these will be real fun to develop...
still no progress visible. Changing status.
