Re: [gentoo-user] Big problem with module-rebuild

2005-11-08 Thread Neil Bothwick
On Tue, 8 Nov 2005 05:47:13 -0800, George Garvey wrote:

Setting AUTOCLEAN to no, generally, will make a mess (in my
 opinion). Then, ALL old copies of things that are updated will be left
 installed. One ends up with multiple installed versions of every
 package on the system eventually.
Maybe just for that one package it would be okay. But it sounds
 like the wrong answer.

I was only suggesting it be used in this case, not as a global setting.

-- 
Neil Bothwick

I have seen the truth, and it makes no sense.


signature.asc
Description: PGP signature


[gentoo-user] Big problem with module-rebuild

2005-11-07 Thread Holly Bostick
.. and that problem is, in short, that the rebuild unmerges the previous
version, in the currently-running (or previous) kernel modules folder,
breaking the previous kernel.

And my question is, how to get it to stop doing that. If Portage has a
FEATURES setting that prevents the previous version being unmerged this
way, I don't know what it is.

Example:

I'm currently using 2.6.13-gentoo-r4, and am compiling 2.6.14-gentoo.

/usr/src/linux points to 2.6.14-gentoo.

module-rebuild rebuild
** Preparing to merge modules:
** Packages which I will emerge are:
=sys-fs/submount-0.9-r2
=media-libs/svgalib-1.9.23
=media-video/ati-drivers-8.18.8-r1

Now, taking the most important of these modules, let's look at what
happens with ati-drivers (it's most important because X is set to
use it, and naturally X won't start if the driver is not found).

| emerge (3 of 3) media-video/ati-drivers-8.18.8-r1 to /
snip
 * Determining the location of the kernel source code
 * Found kernel source directory:
 * /usr/src/linux
 * Found sources for kernel version:
 * 2.6.14-gentoo
 * Checking for MTRR support enabled ...

 [ ok ]
 * Checking for AGP support enabled ...

 [ ok ]
 * Checking for DRM support disabled ...

 [ ok ]
* X11 implementation is xorg-x11.

So, the drivers are going to compile against 2.6.14, which is what I
want, and correct. So far so good.

|  Unpacking source...
 * Unpacking Ati drivers ... [ ok ]
 * Applying fglrx-2.6.14-access_ok.patch ...   [ ok ]
| Source unpacked.
 * Building the DRM module...
make: Entering directory `/usr/src/linux-2.6.14-gentoo'
 snip
make: Leaving directory `/usr/src/linux-2.6.14-gentoo'
| Test phase [not enabled]: media-video/ati-drivers-8.18.8-r1

| Install ati-drivers-8.18.8-r1 into
/var/tmp/portage/ati-drivers-8.18.8-r1/image/ category media-video
 * Installing fglrx module
snip
--- /lib/modules/
--- /lib/modules/2.6.14-gentoo/
--- /lib/modules/2.6.14-gentoo/video/
| /lib/modules/2.6.14-gentoo/video/fglrx.ko
snip
| /usr/lib/opengl/ati/lib/libGL.so.1 - libGL.so.1.2

And the drivers build and install fine... then this:

| Safely unmerging already-installed instance...
snip
==--- cfgpro obj /lib/modules/2.6.13-gentoo-r4/video/fglrx.ko
==--- cfgpro dir /lib/modules/2.6.13-gentoo-r4/video
==--- cfgpro dir /lib/modules/2.6.13-gentoo-r4
snip
Switching to ati OpenGL interface... done
| original instance of package unmerged safely.
Switching to ati OpenGL interface... done

So the rebuild process has *removed* the kernel modules for what will be
the previous kernel when I reboot--- and if my new kernel doesn't boot,
well neither will my previous one, depending on how critical the modules
are (in this case, I just won't have X, but depending on one's setup,
one might have lost something really necessary).

In any case this is really not correct behaviour (I want both the
currently-running kernel module and the future-kernel module to be
installed).

The only way I can see to avoid this is to step through the emerges with
the 'ebuild' command, stopping after 'install', and not performing
'postinst' or 'unmerge' (whichever one is performed at the end to remove
the previously-existing package).

I don't see SLOTs as being precisely appropriate, but I don't see what
other method *might* resolve this, since the previously-installed
package is in this case (in most cases?) *not* the same as the
re-emerged package, because they are compiled against different kernels.

Is there a way to SLOT external kernel modules against the kernel
version it's being compiled against?

This seems to definitely be a bug, but I have not the first clue how to
submit it, nor what against

help, help, help and hope 2.6.14 works, because if it doesn't,
I've got no modules for my previous kernel

Holly
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Big problem with module-rebuild

2005-11-07 Thread Holly Bostick
Neil Bothwick schreef:
 On Mon, 07 Nov 2005 18:26:02 +0100, Holly Bostick wrote:
 
 
 And my question is, how to get it to stop doing that. If Portage
 has a FEATURES setting that prevents the previous version being
 unmerged this way, I don't know what it is.
 
 
 Doesn't AUTOCLEAN=no do this?
 
 It is a separate setting, not a FEATURE.
 
 

Yes, I see that, but since the description of it is not exactly clear, I
don't know if setting it to no would help, except by testing, which
I'm not prepared to do atm:

(from man make.conf)

 AUTOCLEAN = [yes | no]
  Automatically cleans the system by removing outdated
packages which will not remove functionalities or prevent your  system  from
  working.  On  major ABI changes this may need to be set to
off to ensure that the system can be rebuilt using the new libs before
  the old ones are removed. Downgrading with this option
turned off may result in missing symlinks and an inoperable system.
  Defaults to yes.


In this respect, am I to assume that the outdated package is the
previously-installed version? I don't think so; I think this is a
separate process.

I just reinstalled Wine (unrelated, but perhaps appropriate for an
example) and the output does the clean process well after the previous
version (which is in this case the same version) was removed:


| Safely unmerging already-installed instance...
--- !mtime obj /usr/share/wine/wine.inf
snip
--- !targe sym /usr/lib/libwine.so
--- !targe sym /usr/bin/wineg++
--- !targe sym /usr/bin/winecpp
| original instance of package unmerged safely.
 * ~/.wine/config is now deprecated.  For configuration either use
 * winecfg or regedit HKCU\Software\Wine
| Regenerating /etc/ld.so.cache...
| app-emulation/wine-0.9 merged.

| clean: No packages selected for removal.
| Auto-cleaning packages ...

But I could most certainly be reading this all wrong; it would certainly
be an easy solution if that was the case.

Holly
-- 
gentoo-user@gentoo.org mailing list