Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 144333 - --changeduse and --newuse as dynamic package sets.
Summary: --changeduse and --newuse as dynamic package sets.
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Lowest enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 151337 (view as bug list)
Depends on:
Blocks: 181949
  Show dependency tree
 
Reported: 2006-08-18 09:58 UTC by Bruno Laturner Lemes
Modified: 2007-06-29 02:52 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
portage-2.1.3_rc5 patch adding support for --reinstall=changed-use (changed-use.patch,3.17 KB, patch)
2007-06-27 04:28 UTC, Zac Medico
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bruno Laturner Lemes 2006-08-18 09:58:39 UTC
--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.
Comment 1 Zac Medico gentoo-dev 2006-08-18 13:44:58 UTC
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.
Comment 2 Bruno Laturner Lemes 2006-08-18 19:56:34 UTC
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.
Comment 3 Zac Medico gentoo-dev 2006-08-18 20:24:30 UTC
(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

Comment 4 Marius Mauch (RETIRED) gentoo-dev 2006-08-18 21:55:35 UTC
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)
Comment 5 Bruno Laturner Lemes 2006-08-18 23:17:20 UTC
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?
Comment 6 Zac Medico gentoo-dev 2006-08-19 00:01:52 UTC
(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.

Comment 7 Zac Medico gentoo-dev 2006-08-19 00:59:36 UTC
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).
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2007-02-06 00:06:22 UTC
*** Bug 151337 has been marked as a duplicate of this bug. ***
Comment 9 Marius Mauch (RETIRED) gentoo-dev 2007-06-23 18:51:13 UTC
(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?).
Comment 10 Zac Medico gentoo-dev 2007-06-24 19:25:45 UTC
(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.
Comment 11 Zac Medico gentoo-dev 2007-06-27 04:28:11 UTC
Created attachment 123176 [details, diff]
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.
Comment 12 Zac Medico gentoo-dev 2007-06-29 02:52:16 UTC
This has been released in 2.1.3_rc6.