Re: incompatibilities between utilities/busybox/busybox.links & scripts/rootdisk/LINKS
Erik Andersen <andersen@xmission.com> writes:
> On Fri Nov 12, 1999 at 12:09:44AM +0100, Eric Delaunay wrote:
>> I discovered some problems with hardlinks to busybox in rootdisk:
>> true & false are disabled in busybox.def.h but links are still made
>> in the root image.
>
> I have no problem with re-enabling them. Is that what people want?
It sounds like the way to go, yes...
>> It seems there are 2 files that list the names of hardlinks: one
>> built dynamically during busybox compilation and named
>> utilities/busybox/busybox.links and another static in
>> scripts/rootdisk/LINKS. The latter is used to create rootdisk's
>> hardlinks but is not up-to-date.
> Hmm. Why not use something like what I have in the busybox.spec file, i.e:
>
> mkdir -p $DIRECTORY/bin
> h=`cat busybox.links`
> for i in $h ; do
> mkdir -p $DIRECTORY/`echo $i | sed -e 's/\(^.*\/\)\(.*\)/\1/g' `
> (cd $DIRECTORY/bin ; ln -s busybox `echo $i | sed -e 's/\(^.*\/\)\(.*\)/\2/g' ` );
> done
> rm -f $DIRECTORY/bin/busybox
> install -m 755 busybox $DIRECTORY/bin/busybox
>
> that way the links are autogenerated from whatever the current busybox
> includes in the build...
That sounds more robust. Hmm... Could you maybe add this to the
busybox makefile itself, and basically just autogenerate a file such
as what we are using statically in scripts/rootdisk/LINKS?
I don't like all the cross-dependancies in boot-floppies. The more we
can make things modular and self-sufficient, the more maintainable
boot-floppies will be.
>> Another problem is about loadkmap: it is put in /usr/bin by
>> rootdisk.sh but is assumed to be in /bin by dbootstrap (see
>> main_menu.c, line 212) and in /sbin by busybox (see busybox.links).
>> Where is the right directory? This conflict in directory naming
>> has the side effect of disabling keyboard configuration step in
>> dbootstrap.
>
> Somebody tell me where they want it if not in /sbin...
Well, from the FHS standard:
Deciding what things go into "sbin" directories is simple: If a normal
(not a system administrator) user will ever run it directly, then it
should be placed in one of the "bin" directories. Ordinary users
should not have to place any of the sbin directories in their path.
It seems to me that /sbin is the right place and we oughta just fix
dbootstrap and rootdisk.sh.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: