144333 2006-08-18 09:58 0000 --changeduse and --newuse as dynamic package sets. 2007-06-29 02:52:16 0000 1 1 1 Unclassified Portage Development Enhancement/Feature Requests unspecified All Linux RESOLVED FIXED P5 enhancement --- 181949 1 renrutal@gmail.com dev-portage@gentoo.org arfrever@gentoo.org esigra@gmail.com pacho@condmat1.ciencias.uniovi.es renrutal@gmail.com 2006-08-18 09:58:39 0000 --newuse default action is to emerge apps which USE flags have been changed. However, this will also reemerge packages even if you didn't change their flags. I propose a new option to be used with --newuse: --changeduse. It will emerge the packages with new uses AND with USE flags the system admin modified. Resuming: --newuse: (Re)emerges the packages with USEs marked as % and * --newuse --changeduse: (Re)emerges the packages with USEs marked only as * Another enhancement that could be considered is giving --newuse a new behavior: --newuse: Only emerges packages with * --newuse --anewoption: * and % It all depends if % changes are really required while reemerging a system. IMHO, * is more important. zmedico@gentoo.org 2006-08-18 13:44:58 0000 IUSE records the flags that affect a given package. When the package version remains unchanged, a % symbol reflects a change in IUSE. It's possible that % and * may overlap for a given flag. There a many different types of interactions that can happen it's not possible for portage to determine exactly where % and * overlap and where they do not. Thus, portage does not attempt to make that distinction. renrutal@gmail.com 2006-08-18 19:56:34 0000 So if % and * and maybe other types interactions may overlap each other, does that mean they are stored in the same variable/place, even if represent different things? Maybe Portage doesn't need to make distinctions because there aren't any to be done. One IUSE can be fresh, and it can be a newly set IUSE, so %* at the same time. zmedico@gentoo.org 2006-08-18 20:24:30 0000 (In reply to comment #2) > So if % and * and maybe other types interactions may overlap each other, does > that mean they are stored in the same variable/place, even if represent > different things? Yes, and sometimes the information isn't even stored at all. For example, USE flag can affect an ebuild even when it's not listed in IUSE (though it's a QA violation, many ebuilds don't properly specify IUSE). > Maybe Portage doesn't need to make distinctions because there aren't any to be > done. One IUSE can be fresh, and it can be a newly set IUSE, so %* at the same > time. I'm not sure what you mean. It's best expressed in terms of IUSE and USE. These values can be examined via the metadata function of portageq. For example: portageq metadata / ebuild sys-apps/portage-2.1-r2 IUSE portageq metadata / installed sys-apps/portage-2.1-r2 IUSE portageq metadata / installed sys-apps/portage-2.1-r2 USE genone@gentoo.org 2006-08-18 21:55:35 0000 The important thing to note here is that if a flag is added to or removed from IUSE portage can't know what happened: a) a feature that was hard enabled became optional (so the package changes if the flag is not set in USE) b) a new optional feature was added (so the package changes if the flag is set in USE) c) an optional feature is now hard enabled (see a) d) an optional feature was dropped (see b) renrutal@gmail.com 2006-08-18 23:17:20 0000 Thanks for the explanation, now I get the whole difference between USE and IUSE. So, in terms of set theory: A is a set of IUSE of a currently installed version of the package. B is a set of IUSE of a the version of the package to be installed. W = B - A X = A - B if W is not empty then it contains the new IUSE. if X is not empty then it contains the dropped IUSE. --newuse takes care of the cases above. ------ C is the USE set of the moment when the current installed package was emerged. D is the USE set now. E = A intersects C (the enabled IUSE back then) F = B intersects D (the enabled IUSE now) Y = F - E Z = E - F if Y is not empty then it contains the now enabled IUSE. if Z is not empty then it contains the now disabled IUSE. So, if an IUSE was added or dropped, but it wasn't enabled in USE, then there won't be changes, and it won't need a recompilation. --changeduse takes care of these. Now I just need to find out if Portage keeps track of enabled IUSE for each installed package. The change from optional to required dependency and vice-versa isn't treated here, these changes should generate a new ebuild version, at least a new release (-r{DIGIT}). Portage will grab them and just update, even if it's not needed. Usually this kind of change is big enough to get its own version, isn't it? zmedico@gentoo.org 2006-08-19 00:01:52 0000 (In reply to comment #5) > Now I just need to find out if Portage keeps track of enabled IUSE for each > installed package. They're stored in /var/db/pkg/*/*/IUSE and retrievable via the portageq command that I mentioned earlier. > The change from optional to required dependency and vice-versa isn't treated > here, these changes should generate a new ebuild version, at least a new > release (-r{DIGIT}). Portage will grab them and just update, even if it's not > needed. Usually this kind of change is big enough to get its own version, isn't > it? Ideally, yes. However, I'm pretty sure that the behavior of gentoo devs often isn't ideal. In addition, a change in an eclass can affect all the ebuilds that inherit it. In that case it may not be feasible to revbump all of the affected ebuilds. zmedico@gentoo.org 2006-08-19 00:59:36 0000 Sure, we can always add yet another command line option, but perhaps things like --newuse and --changeduse really belong in the realm of packages sets (bug 96088). jakub@gentoo.org 2007-02-06 00:06:22 0000 *** Bug 151337 has been marked as a duplicate of this bug. *** genone@gentoo.org 2007-06-23 18:51:13 0000 (In reply to comment #7) > Sure, we can always add yet another command line option, but perhaps things > like --newuse and --changeduse really belong in the realm of packages sets (bug > 96088). That would likely need sets that can accept arguments and a more complex return type than just atoms (or can we use use-deps for that?). zmedico@gentoo.org 2007-06-24 19:25:45 0000 (In reply to comment #9) > That would likely need sets that can accept arguments and a more complex return > type than just atoms (or can we use use-deps for that?). Well, --newuse and --changeduse aren't really sets by themselves. They're actually package selection modifiers that are applied to normal sets. The --deep and --emptytree modifiers are other examples of this. These package selection modifiers are hardcoded into the current resolver but eventually they'll be split out into separate modules. zmedico@gentoo.org 2007-06-27 04:28:11 0000 Created an attachment (id=123176) portage-2.1.3_rc5 patch adding support for --reinstall=changed-use This implements a --reinstall=changed-use option which behaves like the --changeduse option described in comment #5. zmedico@gentoo.org 2007-06-29 02:52:16 0000 This has been released in 2.1.3_rc6. 123176 2007-06-27 04:28 0000 portage-2.1.3_rc5 patch adding support for --reinstall=changed-use changed-use.patch text/plain SW5kZXg6IGJpbi9lbWVyZ2UKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYmluL2VtZXJnZQkocmV2aXNpb24gNzA1 MikKKysrIGJpbi9lbWVyZ2UJKHJldmlzaW9uIDcwNTMpCkBAIC0zNDIsNiArMzQyLDcgQEAKIAlz dWI9W10KIAlpZiAiLS11cGRhdGUiIGluIG15b3B0cyBvciBcCiAJCSItLW5ld3VzZSIgaW4gbXlv cHRzIG9yIFwKKwkJIi0tcmVpbnN0YWxsIiBpbiBteW9wdHMgb3IgXAogCQkiLS1ub3JlcGxhY2Ui IGluIG15b3B0cyBvciBcCiAJCW15YWN0aW9uIGluICgic3lzdGVtIiwgIndvcmxkIik6CiAJCWFk ZC5leHRlbmQoWyJzZWxlY3RpdmUiXSkKQEAgLTEwNDAsNiArMTA0MSwyMSBAQAogCQlmLmVuZF9w YXJhZ3JhcGgoMSkKIAkJZi53cml0ZXIuZmx1c2goKQogCisJZGVmIF9yZWluc3RhbGxfZm9yX2Zs YWdzKHNlbGYsIGZvcmNlZF9mbGFncywKKwkJb3JpZ191c2UsIG9yZ19pdXNlLCBjdXJfdXNlLCBj dXJfaXVzZSk6CisJCWlmICItLW5ld3VzZSIgaW4gc2VsZi5teW9wdHM6CisJCQlpZiBvcmdfaXVz ZS5zeW1tZXRyaWNfZGlmZmVyZW5jZSgKKwkJCQljdXJfaXVzZSkuZGlmZmVyZW5jZShmb3JjZWRf ZmxhZ3MpOgorCQkJCXJldHVybiBUcnVlCisJCQllbGlmIG9yZ19pdXNlLmludGVyc2VjdGlvbihv cmlnX3VzZSkgIT0gXAorCQkJCWN1cl9pdXNlLmludGVyc2VjdGlvbihjdXJfdXNlKToKKwkJCQly ZXR1cm4gVHJ1ZQorCQllbGlmICJjaGFuZ2VkLXVzZSIgaW4gc2VsZi5teW9wdHMuZ2V0KCItLXJl aW5zdGFsbCIsIiIpLnNwbGl0KCIsIik6CisJCQlpZiBvcmdfaXVzZS5pbnRlcnNlY3Rpb24ob3Jp Z191c2UpICE9IFwKKwkJCQljdXJfaXVzZS5pbnRlcnNlY3Rpb24oY3VyX3VzZSk6CisJCQkJcmV0 dXJuIFRydWUKKwkJcmV0dXJuIEZhbHNlCisKIAlkZWYgY3JlYXRlKHNlbGYsIG15Ymlna2V5LCBt eXBhcmVudD1Ob25lLCBhZGRtZT0xLCBteXVzZT1Ob25lLAogCQlwcmlvcml0eT1EZXBQcmlvcml0 eSgpLCByZXZfZGVwPUZhbHNlLCBhcmc9Tm9uZSk6CiAJCSIiIgpAQCAtMTExMyw3ICsxMTI5LDkg QEAKIAkJCSIiIiBJZiB3ZSBhcmVuJ3QgbWVyZ2luZywgcGVyZm9ybSB0aGUgLS1uZXd1c2UgY2hl Y2suCiAJCQkgICAgSWYgdGhlIHBhY2thZ2UgaGFzIG5ldyBpdXNlIGZsYWdzIG9yIGRpZmZlcmVu dCB1c2UgZmxhZ3MgdGhlbiBpZgogCQkJICAgIC0tbmV3dXNlIGlzIHNwZWNpZmllZCwgd2UgbmVl ZCB0byBtZXJnZSB0aGUgcGFja2FnZS4gIiIiCi0JCQlpZiBtZXJnaW5nPT0wIGFuZCAiLS1uZXd1 c2UiIGluIHNlbGYubXlvcHRzIGFuZCBcCisJCQlpZiBtZXJnaW5nID09IDAgYW5kIFwKKwkJCQko Ii0tbmV3dXNlIiBpbiBzZWxmLm15b3B0cyBvcgorCQkJCSItLXJlaW5zdGFsbCIgaW4gc2VsZi5t eW9wdHMpIGFuZCBcCiAJCQkJdmFyZGJhcGkuY3B2X2V4aXN0cyhteWtleSk6CiAJCQkJcGtnc2V0 dGluZ3Muc2V0Y3B2KG15a2V5LCBteWRiPW15ZGJhcGkpCiAJCQkJZm9yY2VkX2ZsYWdzID0gc2V0 KCkKQEAgLTExMjQsMTIgKzExNDIsOSBAQAogCQkJCQlteWRiYXBpLmF1eF9nZXQobXlrZXksIFsi SVVTRSJdKVswXS5zcGxpdCgpKSkKIAkJCQlvbGRfaXVzZSA9IHNldChmaWx0ZXJfaXVzZV9kZWZh dWx0cygKIAkJCQkJdmFyZGJhcGkuYXV4X2dldChteWtleSwgWyJJVVNFIl0pWzBdLnNwbGl0KCkp KQotCQkJCWlmIGl1c2VzLnN5bW1ldHJpY19kaWZmZXJlbmNlKAotCQkJCQlvbGRfaXVzZSkuZGlm ZmVyZW5jZShmb3JjZWRfZmxhZ3MpOgorCQkJCWlmIHNlbGYuX3JlaW5zdGFsbF9mb3JfZmxhZ3Mo CisJCQkJCWZvcmNlZF9mbGFncywgb2xkX3VzZSwgb2xkX2l1c2UsIG15dXNlLCBpdXNlcyk6CiAJ CQkJCW1lcmdpbmcgPSAxCi0JCQkJZWxpZiBvbGRfaXVzZS5pbnRlcnNlY3Rpb24ob2xkX3VzZSkg IT0gXAotCQkJCQlpdXNlcy5pbnRlcnNlY3Rpb24obXl1c2UpOgotCQkJCQltZXJnaW5nPTEKIAog CQlpZiBhZGRtZSBhbmQgbWVyZ2luZyA9PSAxOgogCQkJbXliaWdrZXkuYXBwZW5kKCJtZXJnZSIp CkBAIC0xNTk1LDcgKzE2MTAsOSBAQAogCQkJCQlpZiBteWViX3BrZ19tYXRjaGVzOgogCQkJCQkJ bXllYl9wa2cgPSBwb3J0YWdlLmJlc3QobXllYl9wa2dfbWF0Y2hlcykKIAotCQkJCWlmIG15ZWJf cGtnIGFuZCAiLS1uZXd1c2UiIGluIHNlbGYubXlvcHRzOgorCQkJCWlmIG15ZWJfcGtnIGFuZCBc CisJCQkJCSgiLS1uZXd1c2UiIGluIHNlbGYubXlvcHRzIG9yIFwKKwkJCQkJIi0tcmVpbnN0YWxs IiBpbiBzZWxmLm15b3B0cyk6CiAJCQkJCWl1c2VzID0gc2V0KGZpbHRlcl9pdXNlX2RlZmF1bHRz KAogCQkJCQkJYmluZGIuYXV4X2dldChteWViX3BrZywgWyJJVVNFIl0pWzBdLnNwbGl0KCkpKQog CQkJCQlvbGRfdXNlID0gYmluZGIuYXV4X2dldChteWViX3BrZywgWyJVU0UiXSlbMF0uc3BsaXQo KQpAQCAtMTYxNCwxMiArMTYzMSw5IEBACiAJCQkJCWlmICItLXVzZXBrZ29ubHkiIG5vdCBpbiBz ZWxmLm15b3B0cyBhbmQgbXllYjoKIAkJCQkJCWN1cl9pdXNlID0gc2V0KGZpbHRlcl9pdXNlX2Rl ZmF1bHRzKAogCQkJCQkJCXBvcnRkYi5hdXhfZ2V0KG15ZWIsIFsiSVVTRSJdKVswXS5zcGxpdCgp KSkKLQkJCQkJaWYgaXVzZXMuc3ltbWV0cmljX2RpZmZlcmVuY2UoCi0JCQkJCQljdXJfaXVzZSku ZGlmZmVyZW5jZShmb3JjZWRfZmxhZ3MpOgorCQkJCQlpZiBzZWxmLl9yZWluc3RhbGxfZm9yX2Zs YWdzKAorCQkJCQkJZm9yY2VkX2ZsYWdzLCBvbGRfdXNlLCBpdXNlcywgbm93X3VzZSwgY3VyX2l1 c2UpOgogCQkJCQkJbXllYl9wa2cgPSBOb25lCi0JCQkJCWVsaWYgaXVzZXMuaW50ZXJzZWN0aW9u KG9sZF91c2UpICE9IFwKLQkJCQkJCWN1cl9pdXNlLmludGVyc2VjdGlvbihub3dfdXNlKToKLQkJ CQkJCW15ZWJfcGtnID0gTm9uZQogCQkJCWlmIG15ZWJfcGtnOgogCQkJCQliaW5wa2d1c2VmbGFn cyA9IFwKIAkJCQkJCXNlbGYudHJlZXNbbXlyb290XVsiYmludHJlZSJdLmRiYXBpLmF1eF9nZXQo CkBAIC01MTQ1LDYgKzUxNTksOSBAQAogCQkJImhlbHAiOiJpbmNsdWRlIHVubmVjZXNzYXJ5IGJ1 aWxkIHRpbWUgZGVwZW5kZW5jaWVzIiwKIAkJCSJ0eXBlIjoiY2hvaWNlIiwKIAkJCSJjaG9pY2Vz IjooInkiLCAibiIpCisJCX0sCisJCSItLXJlaW5zdGFsbCI6IHsKKwkJCSJoZWxwIjoic3BlY2lm eSBjb25kaXRpb25zIHRvIHRyaWdnZXIgcGFja2FnZSByZWluc3RhbGxhdGlvbiIKIAkJfQogCX0K IAo=