Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 207337 - hiding warning when forcing net modules
Summary: hiding warning when forcing net modules
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-25 02:13 UTC by Christohper Harrington
Modified: 2008-02-27 17:55 UTC (History)
1 user (show)

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


Attachments
Patch to net.lo (net.lo.diff,555 bytes, patch)
2008-01-25 02:14 UTC, Christohper Harrington
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christohper Harrington 2008-01-25 02:13:27 UTC
Attached is a very tiny patch to /etc/init.d/net.lo used to hide the ugly two-line warning every time an interface goes up or down.

Appropriately named "i_promise_i_wont_file_any_bugs", setting that in /etc/conf.d/net will eliminate the warning, so I don't feel like a criminal every time I watch my boot sequence.

I'm already braced for this to be rejected, but if it were accepted, I'd advocate never revealing it in any sort of documentation. Anyone smart enough to look in /etc/init.d/net.lo will appreciate and set the variable, and it means I don't have to re-patch my init script every time I update baselayout.

Reproducible: Always

Steps to Reproduce:
1. Reboot.
2. Cry.
3. Set variable.
4. Reboot.
Actual Results:  
5. Cry.

Expected Results:  
5. Yay!
Comment 1 Christohper Harrington 2008-01-25 02:14:12 UTC
Created attachment 141742 [details, diff]
Patch to net.lo
Comment 2 Christohper Harrington 2008-01-25 02:16:37 UTC
Ah, cripes. I'm still new at this. Sorry I made the patch backwards. *smack forehead*
Comment 3 Roy Marples 2008-02-03 23:34:32 UTC
Whilst I laughed at your choice of variable name, I do have reservations about adding this because it might cause ME to think it could be a bug with net module ordering if we didn't see that message.

I would ask why you feel you need to force modules. If it's purely for speed reasons, then please try baselayout-2 or OpenRC where we now cache the module load order, so only the first run is slow on new modules. Subsequent runs are quite fast.
Comment 4 Christohper Harrington 2008-02-04 04:03:47 UTC
I guess I prefer to set the forced modules because I might have different things installed on my systems at once; I actually maintain about 60 different Gentoo desktops. Being able to explicitly name which utility is used, no matter what is installed, eases my mind.

Even though it may be more-or-less superfluous.

As an example, some systems use pump, while others use dhcpcd. There are situations where dhcpcd fails to hang on to an IP for whatever reason (usually a broken router) and pump seems to work fine.

As I said, I'm braced for rejection. If there's a better alternative (like simply removing packages that aren't used) then I'll take the high road.
Comment 5 Roy Marples 2008-02-04 04:08:18 UTC
(In reply to comment #4)
> I guess I prefer to set the forced modules because I might have different
> things installed on my systems at once; I actually maintain about 60 different
> Gentoo desktops. Being able to explicitly name which utility is used, no matter
> what is installed, eases my mind.
> 
> Even though it may be more-or-less superfluous.
> 
> As an example, some systems use pump, while others use dhcpcd. There are
> situations where dhcpcd fails to hang on to an IP for whatever reason (usually
> a broken router) and pump seems to work fine.
> 
> As I said, I'm braced for rejection. If there's a better alternative (like
> simply removing packages that aren't used) then I'll take the high road.

And what stops you from using modules= vs modules_force= for all of that?
All modules_forces does is remove all checking and ordering code.
Comment 6 Christohper Harrington 2008-02-04 05:49:08 UTC
I suppose you're right. I never really thought about it.
Comment 7 Christohper Harrington 2008-02-27 17:55:00 UTC
Closing as invalid.