Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 25438 - fixpackages fails with remote, read-only /usr/portage
Summary: fixpackages fails with remote, read-only /usr/portage
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-28 10:45 UTC by george
Modified: 2011-10-30 22:20 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description george 2003-07-28 10:45:31 UTC
I build packages in a chroot environment on a "build host" and fixpackages does
it's job OK here.  I then mount /usr/portage read-only on a "target host".  I
then have two symptoms, which I guess have a common cause:

When running any emerge command global updates/fixpackages (not sure what I
should call it) insists on running.  This is more than just irritating when
running scripts with many emerge commands.

Running fixpackages fails because /usr/portage is read only.

Reproducible: Always
Steps to Reproduce:
1. mount /usr/portage read only
2.
3.

Actual Results:  
1. Delay on running emerge - similar for any emerge command ....
# emerge -p evolution
 
Performing Global Updates: /usr/portage/profiles/updates/3Q-2002
(Could take a couple minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
........................................................................................
 
 ** Skipping packages. Run 'fixpackages' or set it in FEATURES to fix the
    tbz2's in the packages directory. Note: This can take a very long time.
 
These are the packages that I would merge, in order: ....

2. Running fixpackages ...

# fixpackages
 
Performing Global Updates: /usr/portage/profiles/updates/3Q-2002
(Could take a couple minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
........................................................................................!!!
Cannot update readonly binary: sys-apps/man-pages-1.56
!!! Cannot update readonly binary: gnome-base/gnome-common-1.2.4-r3
!!! Cannot update readonly binary: sys-apps/grep-2.5.1-r1
.....

This continues for (presumably) all binary packages (I haven't checked), and
also for multiple quarterly updates.

Expected Results:  
I would expect the following behaviour - although there are other ways of
achieving sensible results.

1. On "target host" global update message etc should happen no more than the
once that it happens on the "build host".

2. fixpackages should realise, or be told, that it has nothing to do under
/usr/portage and continue with whatever it does elsewhere.

# emerge info
  
Performing Global Updates: /usr/portage/profiles/updates/3Q-2002
(Could take a couple minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
........................................................................................
  
 ** Skipping packages. Run 'fixpackages' or set it in FEATURES to fix the
    tbz2's in the packages directory. Note: This can take a very long time.
Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1)
=================================================================
System uname: 2.4.20-gentoo-r2 i686 Pentium II (Deschutes)
GENTOO_MIRRORS="http://gentoo.oregonstate.edu
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
CONFIG_PROTECT=""
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages/Hosts/olly"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR_OVERLAY="/usr/local/portage"
USE="x86 alsa apm avi bonobo crypt cups dvd encode gif gnome gtk gtk2 java jpeg
mmx mozilla mpeg mysql nas oggvorbis oss pam pdflib pcmcia png quicktime samba
sdl spell sse ssl tiff truetype wmf X zlib"
COMPILER="gcc3"
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=i686 -O3 -pipe"
CXXFLAGS="-march=i686 -O3 -pipe"
ACCEPT_KEYWORDS="x86 ~x86"
MAKEOPTS="-j2"
AUTOCLEAN="yes"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
FEATURES="sandbox ccache"
Comment 1 Nicholas Jones (RETIRED) gentoo-dev 2003-07-28 23:32:52 UTC
fixpackages is optional... Running something to fix binary packages
on a readonly filesystem really doesn't work, so there isn't much
point in you running it at all. The rest of the global updates are
to ensure that you /var/db/pkg tree is up to date. You can just run
fixpackages from the root that has read/write access to the
/usr/portage/packages directory if you like.

Summary: You don't need to run fixpackages.
Comment 2 george 2003-07-29 01:16:56 UTC
I accept that I don't need to run fixpackages - no argument at all.

However I'm still left with emerge on the "target host" trying to do whatever it does when "Performing Global Updates" and, as far as I can tell, failing.  I presume it fails because on the "build host" I see this message once after every emerge sync, but on the "target host" I see it every time I run emerge.

I should have thought it through further before posting the bug - sorry - but this _is_ still a bug: unless mounting /usr/portage read-only is not permitted, and I hope I'm not the only one who thinks that would be a very bad move.
Comment 3 Alec Warner (RETIRED) archtester gentoo-dev Security 2005-01-06 22:17:53 UTC
On the target host try FEATURES="-fixpackages".  Not sure why it's running at every emerge, but see if that fixes it.  I doubt anything will stop it from running during a sync, but you shouldn't be syncing over a read-only FS anyway :p
Comment 4 george 2005-01-22 09:51:17 UTC
I had been doing my remote building another way but I've come back to this way now prompted by Alec's comment.  In short, I don't have to do anything special now and I don't get the problem any more.  Must've been fixed sometime when I wasn't doing this :)

I never run "emerge sync" on the target host anyway - and as you say it makes no sense so I haven't tried it now.

Whether this was consciously fixed or just a happy side-effect, thanks anyway.