In the Gentoo Prefix linux profiles, we have had to package.provide sys-apps/util-linux for multiple issues. package.provided satisfies deps before installed packages. As such, I'm making the util-linux dep in virtual/pager conditional on !prefix. Here is an irc log that explains the situation better: 13:10 < darkside_> on a standard gentoo linux installation. why isn't sys-apps/less depcleaned? sys-apps/util-linux satisfies virtual/pager and is on every system 13:10 < few_> zmedico: pushed to 'backtracking' 13:11 < few_> darkside_: what gives "emerge -cv sys-apps/less" 13:11 < darkside_> sys-apps/less-436 pulled in by: 13:11 < darkside_> virtual/pager-0 13:12 < darkside_> but, util-linux also satisfies virtual/pager 13:14 < darkside_> so, here is the fun bit: once you add sys-apps/util-linux-2 to package.provided then sys-apps/less gets depcleaned 13:14 < darkside_> is that some portage bug? 13:14 < few_> darkside_: and "emerge -cv sys-apps/util-linux"? 13:15 < darkside_> sys-apps/util-linux-2.17.2 pulled in by: sys-fs/e2fsprogs-1.41.12 sys-fs/udev-151-r4 system 13:20 < few_> I think I know what happens. when it searches for something to satisfy the deps of virtual/pager it takes the first atom that is satisfied by an installed package. it doesn't have the information that if it would choose another atom in the ||-dep, it could clean out more packages. 13:20 < few_> and the p.provide helps is caused by special casing for p.provide in the atom selection code. 13:20 < darkside_> and package.provided has higher priority than installed packages? 13:20 < few_> yes 13:21 < few_> so the answer is, that it is caused by the order of the atom in virtual/pagers deps. 13:21 < few_> atoms* 13:22 < darkside_> i see it as the fact that ||-dep handling can be improved and/or is buggy, right? 13:27 < few_> not in your case. what you're asking is to get --depclean to minimize the number of installed packages (instead of going the easy route of pulling in dep after dep and doing a definite choice at each step). 13:29 < darkside_> ok. i give you the following case. in Gentoo Prefix we had to p.provide util-linux in the profiles. now /usr/bin/less is being used instead of $EPREFIX/usr/bin/less 13:30 < darkside_> so..we could add sys-apps/less to the @system set..but would prefer to not diverge away from Gentoo Linux if possible 13:30 < few_> I see 13:31 < darkside_> but, this 'interesting' p.provided handling leaves virtual/pager useless and thus not pulling in *anything* unless you put one of the atoms in your world file 13:31 < darkside_> (or we put one of the atom in @system, but that seems wrong too) 13:32 < few_> no, it's not useless. it's still satisfied. 13:32 < few_> the assumption is that if the user has a p.provide entry he wants to use that package everywhere. 13:32 < darkside_> sure, technically it is satisfied by one atom (that happens to be in p.provided) 13:33 < few_> yeah 13:33 < darkside_> but on Gentoo Linux, virtual/pager is satisfied twice 13:33 < few_> you do not really provide util-linux, do you? 13:33 < darkside_> the system does 13:33 < darkside_> i mean, the host system 13:34 < few_> which means that a pager is installed and usable? 13:35 < darkside_> sure, /bin/more possibly from 10 years ago. it isn't really too usable, I'd say 13:35 < few_> since you're not using gentoo's util-linux, what about removing util-linux from virtual/pager in prefix? 13:35 < few_> hehe 13:36 < few_> or did you try to mask util-linux? no idea what the effect would be 13:36 < darkside_> can't mask it, because other packages depend on util-linux (but work with the host's version so p.provide is fine) 13:37 < ABCD> few_: we don't overlay anything on virtual/*, so we just use the gx86 version of those packages :) 13:37 < darkside_> could probably do prefix? ( util-linux ) in virtual/pager though 13:38 < few_> or that 13:38 < darkside_> !prefix of course 13:39 < darkside_> yea, that will work indeed. /me opens bug 13:41 < few_> good
Committed trivial fix. (This bug was for informational, reference purposes as I intended to fix it myself anyway) + 05 Oct 2010; Jeremy Olexa <darkside@gentoo.org> pager-0.ebuild: + Don't depend on util-linux for Gentoo Prefix, bug 339854
Reopening, because this is only a (dirty) workaround, not a real solution. util-linux installs /bin/more and it is a valid pager. If prefix doesn't need util-linux for certain packages, you should fix those and get rid of the package.provided.
(In reply to comment #2) > Reopening, because this is only a (dirty) workaround, not a real solution. > util-linux installs /bin/more and it is a valid pager. > > If prefix doesn't need util-linux for certain packages, you should fix those > and get rid of the package.provided. > It is already a non-issue for non-prefix platforms... !prefix? ( sys-apps/util-linux ) So, what is the problem here?
<ulm> darkside_: I wonder if the special case for prefix in RDEPEND of virtual/pager could be removed? <ulm> IIRC, it was added because prefix had util-linux in package.provided <ulm> which is no longer the case since quite some time <darkside_> hmm <darkside_> i guess. we don't even have any sys-apps/util-linux[ncurses] ebuilds that are working though <darkside_> so, it shouldn't matter <ulm> prefix/linux/packages even says -*sys-apps/util-linux <ulm> if it makes no difference then I'll remove the USE dependency <darkside_> yes, should be fine + 10 Jan 2012; Ulrich Müller <ulm@gentoo.org> pager-0.ebuild: + Drop USE conditional for prefix, since util-linux is no longer + package.provided in prefix/linux profiles. Bug 339854. Closing.