Mailing List Archive

Strange portage behaviour
Afternoon all,

On one box here, I use the same packages and distfiles directories on both the
main system and a second, small rescue system (the latter is an alternative
boot). The rescue system has the same profile and most of the same USE flags as
its bigger brother, so the packages should be usable directly. The exceptions
relate only to apps that are installed in the main system but not the rescue.

The two systems have their packages defined in sets: @core, @base and, in the
main system, @apps. The world files are empty. I keep the rescue system up to
date by mounting it in a chroot on the main system.

Now, when I chroot into the rescue system and 'emerge -uaDvNk @core @base',
portage reports that it can't use the postfix package because of different USE
flags, but it does the update I've asked for. Postfix is in @apps in the main
system, but it's not installed in the rescue system.

Moreover, if I specify -K instead of -k to emerge, it proposes to install
every package that's present in $PKGDIR.

What can I do about this? Is it expected behaviour?

Or, is there a way to specify 'all installed category/packages that have
usable binary packages'? At present, 'installed' is being ignored.

--
Regards,
Peter.
Re: Strange portage behaviour [ In reply to ]
On Mon, Aug 3, 2020 at 7:45 AM Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> Now, when I chroot into the rescue system and 'emerge -uaDvNk @core @base',
> portage reports that it can't use the postfix package because of different USE
> flags, but it does the update I've asked for. Postfix is in @apps in the main
> system, but it's not installed in the rescue system.

That makes sense. -k says to use the binary if it matches, and
enables --binpkg-respect-use by default. Since the USE flags don't
match it ignores the binary package, but since you're using -k it does
a full build.

>
> Moreover, if I specify -K instead of -k to emerge, it proposes to install
> every package that's present in $PKGDIR.

This is because -k automatically sets --binpkg-respect-use, but -K
does not. So when you switch to -K it ignores your USE flag settings
and just installs them. It will, however, not do any full builds.

> Or, is there a way to specify 'all installed category/packages that have
> usable binary packages'? At present, 'installed' is being ignored.

Sounds like you want --usepkgonly y --binpkg-respect-use y (the first
is the same as -K). At least, I think that is what you're getting at
- I could be misunderstanding your goal.

If I were less lazy I'd come up with a way for portage to have
multiple binpkg files in the repo with different USE flags, and let it
pick the one that matches. It seems possible using config hashes and
a strategy like what is done with shared object symlinks.

--
Rich
Re: Strange portage behaviour [ In reply to ]
On Monday, 3 August 2020 14:18:22 BST Rich Freeman wrote:

> Sounds like you want --usepkgonly y --binpkg-respect-use y (the first
> is the same as -K). At least, I think that is what you're getting at
> - I could be misunderstanding your goal.

Not exactly. I'm finding that emerge -K installs every package whose binpkg
exists, regardless of whether it's installed in the system already. Emerge -k
doesn't. Neither of them takes any notice of what packages are installed in
the system, and I think they should.

Well, that's not quite true. Emerge -k does only reinstall what's already
there, but its checking for USE flag mismatch seems to be done regardless of
that pre-existence.

--
Regards,
Peter.
Re: Strange portage behaviour [ In reply to ]
On Mon, Aug 3, 2020 at 3:01 PM Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> On Monday, 3 August 2020 14:18:22 BST Rich Freeman wrote:
>
> > Sounds like you want --usepkgonly y --binpkg-respect-use y (the first
> > is the same as -K). At least, I think that is what you're getting at
> > - I could be misunderstanding your goal.
>
> Not exactly. I'm finding that emerge -K installs every package whose binpkg
> exists, regardless of whether it's installed in the system already. Emerge -k
> doesn't. Neither of them takes any notice of what packages are installed in
> the system, and I think they should.

-k/K have nothing to do with package selection - just the use of
binary packages.

If you run emerge @core then anything in @core should get installed.
Adding -K or -k will either allow or force the use of binary packages,
but it shouldn't cause stuff that isn't in @core to get installed
unless it is a dependency.

--
Rich
Re: Strange portage behaviour [ In reply to ]
On Monday, 3 August 2020 20:15:45 BST Rich Freeman wrote:
> On Mon, Aug 3, 2020 at 3:01 PM Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> > On Monday, 3 August 2020 14:18:22 BST Rich Freeman wrote:
> > > Sounds like you want --usepkgonly y --binpkg-respect-use y (the first
> > > is the same as -K). At least, I think that is what you're getting at
> > > - I could be misunderstanding your goal.
> >
> > Not exactly. I'm finding that emerge -K installs every package whose
> > binpkg
> > exists, regardless of whether it's installed in the system already. Emerge
> > -k doesn't. Neither of them takes any notice of what packages are
> > installed in the system, and I think they should.
>
> -k/K have nothing to do with package selection - just the use of
> binary packages.
>
> If you run emerge @core then anything in @core should get installed.
> Adding -K or -k will either allow or force the use of binary packages,
> but it shouldn't cause stuff that isn't in @core to get installed
> unless it is a dependency.

That's exactly the problem. It does.

--
Regards,
Peter.
Re: Strange portage behaviour [ In reply to ]
On Monday, 3 August 2020 23:01:07 BST Peter Humphrey wrote:
> On Monday, 3 August 2020 20:15:45 BST Rich Freeman wrote:
> > On Mon, Aug 3, 2020 at 3:01 PM Peter Humphrey <peter@prh.myzen.co.uk>
wrote:
> > > On Monday, 3 August 2020 14:18:22 BST Rich Freeman wrote:
> > > > Sounds like you want --usepkgonly y --binpkg-respect-use y (the first
> > > > is the same as -K). At least, I think that is what you're getting at
> > > > - I could be misunderstanding your goal.
> > >
> > > Not exactly. I'm finding that emerge -K installs every package whose
> > > binpkg
> > > exists, regardless of whether it's installed in the system already.
> > > Emerge
> > > -k doesn't. Neither of them takes any notice of what packages are
> > > installed in the system, and I think they should.
> >
> > -k/K have nothing to do with package selection - just the use of
> > binary packages.
> >
> > If you run emerge @core then anything in @core should get installed.
> > Adding -K or -k will either allow or force the use of binary packages,
> > but it shouldn't cause stuff that isn't in @core to get installed
> > unless it is a dependency.
>
> That's exactly the problem. It does.

I mean, it does while in the chroot. Perhaps I'm setting something up wrongly.

--
Regards,
Peter.
Re: Strange portage behaviour [ In reply to ]
On Monday, 3 August 2020 23:01:07 BST Peter Humphrey wrote:
> On Monday, 3 August 2020 20:15:45 BST Rich Freeman wrote:
> > On Mon, Aug 3, 2020 at 3:01 PM Peter Humphrey <peter@prh.myzen.co.uk>
wrote:
> > > On Monday, 3 August 2020 14:18:22 BST Rich Freeman wrote:
> > > > Sounds like you want --usepkgonly y --binpkg-respect-use y (the first
> > > > is the same as -K). At least, I think that is what you're getting at
> > > > - I could be misunderstanding your goal.
> > >
> > > Not exactly. I'm finding that emerge -K installs every package whose
> > > binpkg
> > > exists, regardless of whether it's installed in the system already.
> > > Emerge
> > > -k doesn't. Neither of them takes any notice of what packages are
> > > installed in the system, and I think they should.
> >
> > -k/K have nothing to do with package selection - just the use of
> > binary packages.
> >
> > If you run emerge @core then anything in @core should get installed.
> > Adding -K or -k will either allow or force the use of binary packages,
> > but it shouldn't cause stuff that isn't in @core to get installed
> > unless it is a dependency.
>
> That's exactly the problem. It does.

Well, I don't know what's going on. Today it all works perfectly.

Sorry about the noise.

--
Regards,
Peter.
Re: Strange portage behaviour [ In reply to ]
On Wednesday, 5 August 2020 17:04:35 BST Peter Humphrey wrote:

> Well, I don't know what's going on. Today it all works perfectly.

...and today it's up to its tricks again, even after a reboot.

If I 'emerge -uaDvNK' in the chroot, portage wants to emerge every package of
which a binpkg exists, but it omits postfix and says it's found a USE flag
mismatch. If I 'emerge -uaDvNk' it only updates the existing installed
packages, but it still complains about the postfix mismatch.

But postfix isn't installed in the chroot system.

Remember: I bind-mount the packages directory of the host to the same place in
the chroot, so it contains the full set of packages, from which I want to
update just those that are installed in the chroot system.

And I have even less idea what's going wrong than ever.

--
Regards,
Peter.
Re: Strange portage behaviour [ In reply to ]
On Thursday, 6 August 2020 16:07:12 BST Peter Humphrey wrote:
> On Wednesday, 5 August 2020 17:04:35 BST Peter Humphrey wrote:
> > Well, I don't know what's going on. Today it all works perfectly.
>
> ...and today it's up to its tricks again, even after a reboot.
>
> If I 'emerge -uaDvNK' in the chroot, portage wants to emerge every package
> of which a binpkg exists, but it omits postfix and says it's found a USE
> flag mismatch. If I 'emerge -uaDvNk' it only updates the existing installed
> packages, but it still complains about the postfix mismatch.
>
> But postfix isn't installed in the chroot system.
>
> Remember: I bind-mount the packages directory of the host to the same place
> in the chroot, so it contains the full set of packages, from which I want
> to update just those that are installed in the chroot system.
>
> And I have even less idea what's going wrong than ever.

A thought: is there a reason not to bind-mount a single directory to two
others at the same time? Or should I chain them instead? I have this in the
host's /etc/fstab:

# NFS-export portage to the compile host:
/var/db/repos/gentoo /mnt/nfs/portage none bind 0 0
/var/cache/packages /mnt/nfs/portage.packages none bind 0 0
/var/cache/distfiles /mnt/nfs/portage.distfiles none bind 0 0

# Use the same packages and distfiles on the local rescue system:
/var/cache/packages /mnt/rescue/var/cache/packages none noauto,bind 0 0
/var/cache/distfiles /mnt/rescue/var/cache/distfiles none noauto,bind 0 0

--
Regards,
Peter.