Portage attempts to use PKGDIR even when PKGDIR is mounted readonly if --getbinpkg is used, or if FEATURES="unmerge-backup" or FEATURES="downgrade-backup". As far as expected behavior is concerned, I assume that the two FEATURES situations would require notifying the user of the issue. Regarding --getbinpkg, in my mind, ideally, the binpkg should be stored in a temporary location, merged, and then removed from the temporary location. This logic for --getbinpkg might not hold if you take a different view, that --getbinpkg is simply to get a remote binpkg, and then it would be used, but the fact that --getbinpkg currently means get pkg and use it, to me implies that the previous logic regarding a tempdir should hold. To reproduce this scenario, mount PKGDIR as readonly by a means of your choice, in my case, nfs readonly, and then either emerge --getbinpkg foo or FEATURES="unmerge-backup" emerge --depclean foo or FEATURES="downgrade-backup" emerge <foo-cur.ver
URL is source of bug discovery
(In reply to NP-Hardass from comment #0) > As far as expected behavior is concerned, I assume that the two FEATURES > situations would require notifying the user of the issue. Regarding > --getbinpkg, in my mind, ideally, the binpkg should be stored in a temporary > location, merged, and then removed from the temporary location. This logic > for --getbinpkg might not hold if you take a different view, that > --getbinpkg is simply to get a remote binpkg, and then it would be used, but > the fact that --getbinpkg currently means get pkg and use it, to me implies > that the previous logic regarding a tempdir should hold. We can add a setting that causes downloaded binary packages to be placed it a temporary directory and deleted after they have been installed. When PKGDIR is readonly, portage could suggest to enable this setting if it isn't already enabled.
(In reply to NP-Hardass from comment #0) > Portage attempts to use PKGDIR even when PKGDIR is mounted readonly if > --getbinpkg is used, or if FEATURES="unmerge-backup" or > FEATURES="downgrade-backup". > > As far as expected behavior is concerned, I assume that the two FEATURES > situations would require notifying the user of the issue. Regarding > --getbinpkg, in my mind, ideally, the binpkg should be stored in a temporary > location, merged, and then removed from the temporary location. This logic > for --getbinpkg might not hold if you take a different view, that > --getbinpkg is simply to get a remote binpkg, and then it would be used, but > the fact that --getbinpkg currently means get pkg and use it, to me implies > that the previous logic regarding a tempdir should hold. This is just plain stupid. If you want binary packages in a temporary directory, set PKGDIR to that directory instead of expecting Portage to do special magic to workaround invalid configuration.
(In reply to Michał Górny from comment 3) > > This is just plain stupid. If you want binary packages in a temporary > directory, set PKGDIR to that directory instead of expecting Portage to do > special magic to workaround invalid configuration. I agree that the FEATURES are a misconfiguration. --getbinpkg allows fetching of packages from a remote location. In this scenario, being unable to use remote packages when a local pkgdir is not a not a misconfiguration issue, in my opinion, and the temp dir during the emerge process is a reasonable remedy.