Hi, Alan.
On Sun, Jan 20, 2013 at 11:18:40PM +0200, Alan McKinnon wrote:
> On Sun, 20 Jan 2013 20:50:12 +0000
> Alan Mackenzie <[email protected]> wrote:
> > Hi, Gentoo!
> > After synching, I've got a whole lot of programs to emerge, amongst
> > them being udev-197. :-( I'd rather do this on its own, in peace
> > and quiet, rather than together with 12 or 13 other programs.
> > emerge -puND world generates these:
> > [ebuild U #] sys-fs/udev-197-r4 [171-r9] USE="acl%* kmod%*
> > openrc%* -doc% -static-libs%" [ebuild U #] virtual/udev-197 [171]
> > . The # indicates the packages are masked in packages.mask, which
> > indeed they are. The emerge man-page indicates that these new
> > versions will nevertheless be merged. But surely this is what the
> > entry in packages.mask is to prevent? Why does emerge want to merge
> > udev-197 in this case? How do I stop it?
> > What am I missing here?
> My reading of that man page is that the #/*/~ output characters do not
> indicate what emerge will do, they indicate if any sort of mask exists
> at the ebuild and tree level. In other words, that udev version is
> somehow listed in one of the various masking methods and portage is
> confirming that for you.
> However, portage is going to install it anyway which can only be
> because you have some unmask setting (probably a local one) which is
> overriding the mask setting, you just need to find where you did it.
That was it, sort of.
emerge decided to install sys-fs/udisks-1.0.4-r4 (presumably this had
just become stable), and this had a dependency on
>=virtual/udev-197[gudev,hwdb]
. So rather than refusing to merge udisks, it insisted on merging
udev-197. This strikes me as a bug, not a feature, but who am I to
pronounce on these matters?
Just as soon as I put ">=udisks-1.0.4-r4" (and a similar entry for
udev-init-scripts) into package.mask, I got a clean reply from "emerge
-puND world".
Anyway, I'll probably do that tomorrow, then start considering udev-197
and all the pain and grief it'll bring me.
[ .... ]
> In plain English I take that to mean: In spite of a mask existing for
> the package, portage is going to merge it anyway as something somewhere
> overrides the mask (and portage unhelpfully declined to tell me where
> that override is coming from...)
Actually, it did tell me, a few lines below, but in emerge's customary
terse fashion which I missed first time round.
Anyhow thanks for the help.
> --
> Alan McKinnon
> [email protected]
--
Alan Mackenzie (Nuremberg, Germany).
