Mike Frysinger schrieb:
>>>> I would be willing to help creating these. Perhaps
>>>> they could be included in busybox package and installed as an option?
>>> no
>> just an idea... There could be an additional busybox-initd package with
>> those scripts. The ebuild could have busybox as dependency and if for
>> example USE=syslog, it would install check the busybox config if syslog
>> is enabled and it would provide a virtual/logger.
I had this idea, too, but after I have send my email.

> 
> i think the best from a support stand point would be to have a busybox-initd 
> package that'd parse the busybox config file to see what is enabled, and then 
> copy the relevant init.d scripts from the portage tree.  creating independent 
> scripts is just a maintenance nightmare.
> 
> so if busybox supports hdparm, it'd do:
> newinitd ${PORTDIR}/sys-apps/hdparm/files/hdparm-init-8 hdparm
> newconfd ${PORTDIR}/sys-apps/hdparm/files/hdparm-conf.d.3 hdparm

That sounds really interesting. Never realized, that something like this
could be used. But if you do this, all scripts have to work with
"standard" tool and bb version, e.g. bb syslogd does not create a pid
file in /var/run. There are also some things, which work different with
bb, e.g. setting consolefont and keymap. And there are some tools, where
I do not see a comparing standard tool (or at least I think there is no
tool), e.g. httpd of busybox.

So perhaps the best method would be making standard tools of bb like
syslogd or hdparm working with the init scripts and create init scripts
for all other bb tools of interest, where no init script exists? In case
of hwclock this is already done by Roy in baselayout-2, but for
consolefont and keymap loading he proposes to create separate init
scripts, since the bb tools do work completely different.

Regards
Marc

-- 
[EMAIL PROTECTED] mailing list

Reply via email to