[gentoo-portage-dev] multiple kernel driver emerges

[gentoo-portage-dev] multiple kernel driver emerges

[Brian]

A problem that I (and others) have is portage unmerging kernel drivers
from an existing kernel when emerging them to a new kernel.
ala

emerge nvidia-kernel
emerge alsa-driver

unmerges the driver from your current kernel before you have a known
good new kernel.

Is there a current method for doing so that I missed?  If not could an
additional protected flag be set to prevent unmerging if the kernel
version is different than the last emerge of the driver, similar to the
slot #?

it would make life a lot easier for noobs & non experts to work out
kerenel configs without messing up a working kernel.

-- 
Brian <dol-sen@telus.net>


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] multiple kernel driver emerges

[Scott Taylor]

The wisdom that had been passed on to me to protect things like that
from being deleted *by portage* is to "touch filename" on the
appropriate modules in the lib/modules/... directory. Because if its
been modified, portage is not supposed to remove it.

The other issue that comes up is when compiling the kernel itself, the
kernel's "make modules_install" and such cleans out all the files in
/lib/modules/kernel-*/kernel/... This is a nuisance in that you may
easily forget to re-emerge the outside modules (xfree-drm for example).

It appears though that anything in a non-kernel-made directory like
/lib/modules/kernel-*/[misc,local] does not get erased when the kernel
is rebuilt. So you might try copying such modules to a different
subdirectory of your own choosing. If its not where portage put it,
portage won't yank it. If its not where the kernel's make cleans out,
that won't delete it either. Doing that means manual effort (and the
chance to overlook it) if the module itself gets re-emerged.

Perhaps there could be a way for an ebuild to mark a file as one that is
allowed to be overwritten but not backed out? That might even be able to
be done by making portage "forget" the timestamp of a kernel module
whenever its installed. Since the timestamp wouldn't match what is on
the disk, it wouldn't delete it, but the next emerge could overwrite
it...

On Fri, 2004-01-02 at 00:16, Brian wrote:
> A problem that I (and others) have is portage unmerging kernel drivers
> from an existing kernel when emerging them to a new kernel.
> ala
> 
> emerge nvidia-kernel
> emerge alsa-driver
> 
> unmerges the driver from your current kernel before you have a known
> good new kernel.
> 
> Is there a current method for doing so that I missed?  If not could an
> additional protected flag be set to prevent unmerging if the kernel
> version is different than the last emerge of the driver, similar to the
> slot #?
> 
> it would make life a lot easier for noobs & non experts to work out
> kerenel configs without messing up a working kernel.
--
Scott Taylor - <security@303underground.com> 

furbling, v.:
	Having to wander through a maze of ropes at an airport or bank
	even when you are the only person in line.
		-- Rich Hall, "Sniglets"

    


--
gentoo-portage-dev@gentoo.org mailing list

[gentoo-portage-dev] kernel drivers vs. portage

[Drake Wyrm]

On Fri, Jan 02, 2004 at 12:31:46AM -0700, in <1073028705.11194.66.camel@Star.BerthoudWireless.net>, Scott Taylor <security@303underground.com> wrote:
> Perhaps there could be a way for an ebuild to mark a file as one that is
> allowed to be overwritten but not backed out? That might even be able to
> be done by making portage "forget" the timestamp of a kernel module
> whenever its installed. Since the timestamp wouldn't match what is on
> the disk, it wouldn't delete it, but the next emerge could overwrite
> it...
It occurs to me that this would be a great extension of Portage's config-protect features. I've been giving this some serious (if somewhat armchair-quarterback) thought. And now, the "There oughtta be a way..." portion of our show!

Currently, metadata is maintained regarding which files were installed by which packages. An additional set of metadata could be maintained regarding which packages "own" installed files. Rather than relying on mtimes and directories (which could be viewed as a simple claim of ownership), allow ebuilds to install files with properties which control how ebuilds interact in the live filesystem. Altogether, these ideas are very close to the status quo with some improvements in structure.

* "World" Any ebuild may clobber a World file; largely the way things work right now, ergo any file installed without specific properties is assumed to be World file; Portage may or may not referee; most appropriate where other mechanisms of fair play exist (e.g. /usr/share/doc, where each ebuild installs into its own directory; /usr/share/application-registry, again regulated by well-chosen namespace)
* "System" Any ebuild may clobber a System file with another system file, but not with a World file; Portage will not remove a System file until the last ebuild which claims it is uninstalled
* "Config" An ebuild may only clobber its own Config files, but are always free to do so; slots play into this one; Portage referees
* "Protected" An ebuild may only clobber its own Protected files, and only if they have not been modified since installation; this is analogous to the current config-protect system with etc-update administrative intervention; Portage will never overwrite or delete a Protected file

The next, and possibly most (important|difficult|confusing), part of my idea is the ability of ebuilds to defer to other specific ebuilds. Rather than masking between ebuilds that overlap in function, or always blocking a portion of one install to prevent conflict, arrange for one ebuild to defer to its better-suited counterpart. The deferring ebuild will not clobber its counterpart's System files (even though it otherwise could) and the deferred-to ebuild will be able to clobber its counterpart's Config files (even though it otherwise couldn't).

Other random possibilities include allowing ebuilds to tag a file as System, Config, or Protected without trying to replace it. This would prevent a loss of functionality which, though not sufficient for a DEPEND, could be crippling if suddenly ripped out from a configured system.

Truth-be-told, I come nowhere near the required ability for implementing something like this, nor is this a finished concept/proposal. However, it's on the table; rip it to shreds.

-- 
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
  --Ghost in the Shell

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] kernel drivers vs. portage

[Drake Wyrm]

What? No opinions, or everybody thinks I'm too much of an idiot to bother answering?

-- 
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
  --Ghost in the Shell

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] kernel drivers vs. portage

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

On 01/04/04  Drake Wyrm wrote:

> What? No opinions, or everybody thinks I'm too much of an idiot to
> bother answering?

I think Daniel fixed that already by using the 'don't unmerge' feature
of CONFIG_PROTECT for /lib/modules.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] kernel drivers vs. portage

[Paul Varner]

On Sun, 2004-01-04 at 09:17, Marius Mauch wrote:
> On 01/04/04  Drake Wyrm wrote:
> 
> > What? No opinions, or everybody thinks I'm too much of an idiot to
> > bother answering?
> 
> I think Daniel fixed that already by using the 'don't unmerge' feature
> of CONFIG_PROTECT for /lib/modules.

It is fixed in the version of portage that is in CVS, but the fix still
hasn't made it to the versions of portage that are marked stable.  In
the CVS tree it was placed in version 1.345 of portage.py.  The version
that is being distributed is currently 1.341 (See my comments at the end
of bug #1477)

A manual work around that I have tested is to use env
CONFIG_PROTECT="/lib/modules" when re-emerging packages such as
alsa-driver for a new kernel.  However, I don't recommend placing it
into the make.conf as typically you only want to protect the
/lib/modules directory when doing the above.

I also would like portage-ng to handle kernel modules dependencies in a
more automated fashion.  Someone commented that revdep-rebuild was a
hack to get around some of the dependency shortcomings in the current
version of portage.  The kernelmod-rebuild script that I recently wrote
is also such a hack.

I didn't comment on the previous message as I didn't see anything that I
disagreed with from a requirements perspective.

Regards,
Paul
-- 
My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] kernel drivers vs. portage

[Brian]

On Sun, 2004-01-04 at 09:30, Paul Varner wrote:
> On Sun, 2004-01-04 at 09:17, Marius Mauch wrote:
> > On 01/04/04  Drake Wyrm wrote:
> > 
> > > What? No opinions, or everybody thinks I'm too much of an idiot to
> > > bother answering?
> > 
> > I think Daniel fixed that already by using the 'don't unmerge' feature
> > of CONFIG_PROTECT for /lib/modules.
> 
> It is fixed in the version of portage that is in CVS, but the fix still
> hasn't made it to the versions of portage that are marked stable.  In
> the CVS tree it was placed in version 1.345 of portage.py.  The version
> that is being distributed is currently 1.341 (See my comments at the end
> of bug #1477)
> 
> A manual work around that I have tested is to use env
> CONFIG_PROTECT="/lib/modules" when re-emerging packages such as
> alsa-driver for a new kernel.  However, I don't recommend placing it
> into the make.conf as typically you only want to protect the
> /lib/modules directory when doing the above.
> 
> I also would like portage-ng to handle kernel modules dependencies in a
> more automated fashion.  Someone commented that revdep-rebuild was a
> hack to get around some of the dependency shortcomings in the current
> version of portage.  The kernelmod-rebuild script that I recently wrote
> is also such a hack.
> 
> I didn't comment on the previous message as I didn't see anything that I
> disagreed with from a requirements perspective.
> 
> Regards,
> Paul
-- 
Thank you for working out this problem.  I, for a second thought I may
have instigated a change in portage for the better, but seeing the above
metioned bug I see it dates back much farther.   Even the fix has been
done for several months.

Again, thank you for the hard work to improve portage.

A side note:  Could changes, such as added features, or changed
functionality in core projects such as portage be announced in the GWN
as they make it to stable. (If it is not already normal)  It may be one
of the best ways for users to learn about such changes.

--
Brian <dol-sen@telus.net>


--
gentoo-portage-dev@gentoo.org mailing list