Mailing List Archive

On Thursday 23 September 2004 11:02, Edward Epstein wrote:
> Thus spake Jason Stubbs:
> >I just realized you're using a cascading profile with portage-2.0.50.
>
> Might you be able to tell me what a cascading profile is? I'm curious to
> know for future reference.

The flat profile is profiles/hardened-x86-2004.0 and the cascaded version is
profiles/hardened/x86. In profiles/hardened/x86 you will find a parent file
which contains a relative path to the parent of the profile. Following those
links you get:

profiles/base
profiles/hardened
profiles/hardened/x86

Each of the files are combined to produce the final profile with any
conflicting settings in the parents being overriden by the children. This
should have no impact on usage but is simply makes maintenance easier. If
something needs to change in all the profiles, the change can be made in
profiles/base and then be inherited by all the others rather than changing
each individual profile.

The profile that you are currently using is profiles/hardened/x86/2.6. This
profile takes all the settings from the profiles/hardened/x86 profile and
then overrides the defaults for virtual/linux-sources and virtual/modutils. A
flat profile would be a complete duplicate of all the files with those
changes applied.

Why shouldn't they be used with 2.0.50? Essentially, they were added to 2.0.50
as a "hidden feature". In other words, they were added so that
semi-widespread testing could be done. After some time it was found that the
implementation was sorely lacking and was redone completely. However, it was
done in CVS and so is in >=2.0.51_preX but was never back-ported to 2.0.50
because of the scope of the change. Thus 2.0.50 still has only a partially
working implementation.

Anyway, there was a recent push to thoroughly test cascading profiles so that
they can be used with the upcoming 2004.3 release. Somehow this turned into
use cascading profiles now and deprecate the old-style ones. You ever play
that game where everybody sits in a circle and whispers a message on to the
next person? Something like that...

portage-2.0.51_rc1 is ~arch at the moment and will hit stable in a few days.
Unless the NFS bug (#63433) affects you, it won't hurt to jump the gun.

Regards,
Jason Stubbs

--
gentoo-user@gentoo.org mailing list

Thus spake Jason Stubbs:

>On Thursday 23 September 2004 11:02, Edward Epstein wrote:
>> Thus spake Jason Stubbs:
>> >I just realized you're using a cascading profile with portage-2.0.50.
>>
>> Might you be able to tell me what a cascading profile is? I'm curious to
>> know for future reference.
>
>The flat profile is profiles/hardened-x86-2004.0 and the cascaded version is
>profiles/hardened/x86. In profiles/hardened/x86 you will find a parent file
>which contains a relative path to the parent of the profile. Following those
>links you get:
>
>profiles/base
>profiles/hardened
>profiles/hardened/x86
>
>Each of the files are combined to produce the final profile with any
>conflicting settings in the parents being overriden by the children. This
>should have no impact on usage but is simply makes maintenance easier. If
>something needs to change in all the profiles, the change can be made in
>profiles/base and then be inherited by all the others rather than changing
>each individual profile.
>
>The profile that you are currently using is profiles/hardened/x86/2.6. This
>profile takes all the settings from the profiles/hardened/x86 profile and
>then overrides the defaults for virtual/linux-sources and virtual/modutils.
> A flat profile would be a complete duplicate of all the files with those
> changes applied.
>
>Why shouldn't they be used with 2.0.50? Essentially, they were added to
> 2.0.50 as a "hidden feature". In other words, they were added so that
>semi-widespread testing could be done. After some time it was found that the
>implementation was sorely lacking and was redone completely. However, it was
>done in CVS and so is in >=2.0.51_preX but was never back-ported to 2.0.50
>because of the scope of the change. Thus 2.0.50 still has only a partially
>working implementation.
>
>Anyway, there was a recent push to thoroughly test cascading profiles so
> that they can be used with the upcoming 2004.3 release. Somehow this turned
> into use cascading profiles now and deprecate the old-style ones. You ever
> play that game where everybody sits in a circle and whispers a message on
> to the next person? Something like that...
>
>portage-2.0.51_rc1 is ~arch at the moment and will hit stable in a few days.
>Unless the NFS bug (#63433) affects you, it won't hurt to jump the gun.

Thanks Jason, I did the upgrade of portage and, apart from a series of QA
notices when I first ran emerge, everything seems to be working fine and
modutils went away.

>Regards,
>Jason Stubbs

Cheers,
Ed

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

--

"It has been said that man is a rational animal. All my life I have
been searching for evidence which could support this."
--Bertrand Russell.

"The American empire is ideological, not territorial. We are the most
ideological people in the world, and we are so united in our view that we
don't understand there can be other views."
--Lt. Gen. William Odom, ret. (Former Director of NSA).

"When I was in school, I cheated on my metaphysics exam: I looked into the
soul of the boy sitting next to me.
--Woody Allen

"Nothing takes the taste out of peanut butter quite like unrequited love."
--Charlie Brown

--
gentoo-user@gentoo.org mailing list

> Thanks Jason, I did the upgrade of portage and, apart from a series of QA
> notices when I first ran emerge, everything seems to be working fine and
> modutils went away.

Same here. Good call Jason.

- Grant

--
gentoo-user@gentoo.org mailing list

> virtual/modutils sys-apps/module-init-tools sys-apps/modutils

Well, that's wrong. You shouldn't have modutils installed, and if you
haven't, than this entry is wrong.

I had that entry once too, and but i didn't had modutils installed, and
emerge -uD world always wanted to install it because of this entry.

BTW: in future portage version, there is no virtuals file anymore, since
portage collects that information from the installed packages in that
future version.


--
gentoo-user@gentoo.org mailing list

Daniel Drake <dsd@gentoo.org> writes:

> However, you still have modutils installed. A new modutils enters portage. A
> gazillion users (who are running 2.6) merge it, not knowing the difference
> between modutils and module-init-tools. modutils overwrites the 2.6
> module-init-tools binaries. You reboot, and you can't load modules.
>
> To try and combat this, we have made modutils block module-init-tools. I don't
> regard this as a perfect solution, its still too confusing and not documented.

Would a "better" solution not be to depreciate modutils and use
module-init-tools for both 2.4 and 2.6? I have not looked in detail at
the gentoo version, but the 'raw' module-init-tools works perfectly
well with kernel 2.4 as it detects which kernel is running and 'does
the right thing'.

--
gentoo-user@gentoo.org mailing list

I just took notice of this thread, and had a look at my own system.
I run the 2.6 win4lin kernel, and have the virtual entry

virtual/modutils sys-apps/module-init-tools sys-apps/modutils

this surprised me a bit, but when I looked, I found that indeed I have
both installed. This strikes me as perhaps not a wonderful thing.
Should I unmerge modutils? Should I also mask it somehow?
Should I just forget it?

++ kevin


On Thu, 23 Sep 2004 13:19:05 +0100, Graham Murray <graham@gmurray.org.uk> wrote:
> Daniel Drake <dsd@gentoo.org> writes:
>
> > However, you still have modutils installed. A new modutils enters portage. A
> > gazillion users (who are running 2.6) merge it, not knowing the difference
> > between modutils and module-init-tools. modutils overwrites the 2.6
> > module-init-tools binaries. You reboot, and you can't load modules.
> >
> > To try and combat this, we have made modutils block module-init-tools. I don't
> > regard this as a perfect solution, its still too confusing and not documented.
>
> Would a "better" solution not be to depreciate modutils and use
> module-init-tools for both 2.4 and 2.6? I have not looked in detail at
> the gentoo version, but the 'raw' module-init-tools works perfectly
> well with kernel 2.4 as it detects which kernel is running and 'does
> the right thing'.
>
>
>
> --
> gentoo-user@gentoo.org mailing list
>
>



--
Kevin O'Gorman, PhD
want a free gmail account? email me for an invitation

--
gentoo-user@gentoo.org mailing list

I did the same <G>. I am now on 2.6 and don't plan to go back to 2.4 so I unmerged the old one.

>
> From: "Kevin O'Gorman" <kogorman@gmail.com>
> Date: 2004/09/23 Thu PM 02:00:27 GMT
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] Why modutils now?
>
> I just took notice of this thread, and had a look at my own system.
> I run the 2.6 win4lin kernel, and have the virtual entry
>
> virtual/modutils sys-apps/module-init-tools sys-apps/modutils
>
> this surprised me a bit, but when I looked, I found that


--
gentoo-user@gentoo.org mailing list

On Thu, 23 Sep 2004 14:03:42 +0000, brettholcomb@charter.net
<brettholcomb@charter.net> wrote:
> I did the same <G>. I am now on 2.6 and don't plan to go back to 2.4 so I unmerged the old one.
>

I think the issue (assuming I understood the response I got earlier)
is that unmerging modutils will erase a few things provided by
module-init-tools, so last evening I did:

emerge -C modutils
emerge module-init-tools

Now my /var/cache/edb/virtuals file looks like:

virtual/modutils sys-apps/module-init-tools

and I have rebooted successfully.

Hope this helps,
Mark

--
gentoo-user@gentoo.org mailing list

On Thu, 23 Sep 2004 18:49:28 +0100, Daniel Drake <dsd@gentoo.org> wrote:
> Mark Knecht wrote:
> > I think the issue (assuming I understood the response I got earlier)
> > is that unmerging modutils will erase a few things provided by
> > module-init-tools, so last evening I did:
>
> Incorrect. unmerging modutils is fine - portage will realise that (for
> example) the "modprobe" binary has changed since modutils was installed, so it
> won't remove it.
>
> However, if you merge modutils over the top of module-init-tools, the
> module-init-tools version of modprobe will be lost.
>
> Daniel
>
>

Ah - thanks for the clarification. It's important. However, without
some study in log files or somewhere else, if someone sees that both
are installed they wouldn't know if they had the modprobe binary from
modutils or module-init-tools.

Good to have this cleaned up. Thanks for the inputs.

- Mark

--
gentoo-user@gentoo.org mailing list

Mark Knecht wrote:
> I think the issue (assuming I understood the response I got earlier)
> is that unmerging modutils will erase a few things provided by
> module-init-tools, so last evening I did:

Incorrect. unmerging modutils is fine - portage will realise that (for
example) the "modprobe" binary has changed since modutils was installed, so it
won't remove it.

However, if you merge modutils over the top of module-init-tools, the
module-init-tools version of modprobe will be lost.

Daniel

--
gentoo-user@gentoo.org mailing list