One way to possibly do this, is to have BSD style inits, do a little trick..
i.e. in /etc/local-packages, or some other directory place scripts.. in one
of the last rc scripts, do something similar to this (under bash):
for x in /usr/local-packages/*
do if [-x $x] $x
endif
done
or whatever the if statement is to check if the file is executable -- i
haven't scripted in bash for awhile, forgive my stupidity if something is
screwed up with the above, if something like that is done though, just make
sure its a common standard. on my redhat system, i have a hack in rc.local
to do this so I can just make one script for each extra thing i want loaded,
so i don't have one massivly large file, and i can electivly choose to enabl
e or disable them based on file permissions. The linux distribution I was
working on used the above method to load/init local packages, only there
were a few subdirectories off of that that helped break down runlevels (my
entire init was based off of the above concept, it wasn't sysvish or bsdish
really...).
Justin
----- Original Message -----
From: "Warren Young" <tangent@cyberport.com>
To: "Linux Kernel Mailing List" <linux-kernel@vger.rutgers.edu>
Sent: Friday, June 16, 2000 9:14 PM
Subject: Re: (reiserfs) Re: Red Hat (was Re: reiserfs)
> Ross Vandegrift wrote:
> >
> > 1) The "feed a script to this program" was designed to work with SYSV
> > style init scripts and there was fear of vendors starting to design
> > programs that only took into account SYSV style of initialization.
>
> BSD got many things right, it's true, but once in a while AT&T did
> something right, too.
>
> Let's turn this around: how would _you_ write a mechanism that would
> allow an arbitrary package to add itself to a BSDish system's bootup
> process without changing existing init scripts? That last condition's
> important: programs that change existing scripts tend to be brittle:
> they often break the scripts they change. The System V init script
> method means you don't have to change existing scripts.
>
> One other condition: you don't have the option of asking the user to
> change their own init scripts to start the package. The track to world
> domination doesn't allow it.
>
> > of preference; I think it makes more sense to run
> > /usr/local/enlightenment/bin/enlightenment than
> > /usr/local/bin/enlightenment. This way, I install all of the software I
> > compile into /usr/local/$(application name), and copy the shared libs to
> > /usr/local/lib. This way, 'ls /usr/local' give a complete view of what
I
> > have installed, no package manager necessary.
>
> 1) Package managers are good. Whether you can get by without them is
> not even an issue: people like them, so mainstream distros will offer
> them, and therefore we might as well design for systems that use them.
>
> 2) The /usr/local/{package} scheme sounds a lot like "c:\Program Files"
> to me. Unix's treatment of PATH versus Windows' is one of the many
> reasons I prefer Unix. If you wanna turn Unix into Windows, grand, but
> don't make me use it.
>
> --
> = Warren Young, maintainer of the Winsock Programmer's FAQ at:
> = http://www.cyberport.com/~tangent/programming/winsock/
> =
> = ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:13 EST