Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 192267 - sys-apps/baselayout-2.0.0_rc4-r1 does not create rc-depend
Summary: sys-apps/baselayout-2.0.0_rc4-r1 does not create rc-depend
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High normal
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-12 07:30 UTC by Martin Väth
Modified: 2007-10-09 10:24 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 Martin Väth 2007-09-12 07:30:42 UTC
Since baselayout-2 got my boot order wrong after upgrade, I was looking for something like depscan.sh -u to repair it. Looking at the sources, it seems to me that this was replaced by rc-depend --update. (BTW: Perhaps this should be documented somewhere, at least in ChangeLog or better in a NEWS file, possibly even in ewarn.)
Unfortunately, rc-depend was not installed on my system:
It appears that it was forgotten to add rc-depend to SBINLINKS in src/Makefile
and perhaps also mountinfo and fstabinfo was supposed to be added to BINLINKS.
Comment 1 Roy Marples (RETIRED) gentoo-dev 2007-09-12 07:43:13 UTC
rc-depend has been moved into /lib/rcscripts/bin as it's not really for user consumption. Or it shouldn't be at any rate :)

Why don't you give some details about what you think is wrong with the boot order instead and we'll work from there?
Comment 2 Martin Väth 2007-09-12 14:07:31 UTC
It was "wrong" with the boot order that none of my own scripts were started at default runlevel (although they were symlinked in /etc/runlevels/default pointing to /etc/init.d/), not matter how often I rebootet. Probably the problem is not very reproducable, because on another system I did exactly the same thing and everything worked smoothly.
Anyway, after "(exec -a rc-depend rc --update)" everything worked also on the other system.

IMHO the user should have documented means to use something like rc-depend --update (or depscan.sh -u) not only in case of such a "bug" but also if he e.g. changed /etc/runlevels/*/* manually or modified some dependency requirement in some /etc/init.d, even if these file does not have a new timestamp (this happens e.g. often when (parts of a) system  config is "cloned" to anther one - it would be rather inconvenient to run rc-update for each changed file in such a case): Also with baselayout-1 such changes were usually not recognized (which is not surprising: how should they?), but after running depscan.sh -u everything worked fine.

It is even *necessary* to be sure about the dependeny order before booting if some scripts (which "use localmount") lie on another partition. This is not a rare case if you have a dual-boot (e.g. 64bit and 32bit gentoo) system, since it is much easier to edit only *one* copy of an initscript than to manage two identical copies lying on two different partitions...
Comment 3 Roy Marples (RETIRED) gentoo-dev 2007-10-09 09:46:59 UTC
It sounds like this is a dupe of #113755, which was caused by an invalid stage tarball.
Comment 4 Martin Väth 2007-10-09 10:09:32 UTC
(In reply to comment #3)
> It sounds like this is a dupe of #113755

I do not think so, since IIRC the scripts were not reported as "broken" but just as "not started" (unfortunately, I do not know how to produce the problem - it occurs very seldom). I am rather sure that the problem is in my case that sometimes(??) baselayout recalculates dependency at boot time before "localmount" which cannot work in my setting since my own scripts are not visible at this time (I collect them in another partition to share them via symlinks for 32bit and 64bit gentoo installation).

I solved the problem now in my case by adding an initscript into boot runlevel which depends on localmount and calls /lib/rcscripts/bin/rc-depend --update (all my other shared scripts are in runlevel "default", so this script is certainly executed before my other scripts). Not sure whether this is a clean solution, but since I have this script, the problem did not re-occur.
Comment 5 Roy Marples (RETIRED) gentoo-dev 2007-10-09 10:24:02 UTC
We require all init scripts to be visible on the root partition for baselayout-2 for exactly this reason.