From: Dumas Patrice (dumas@centre-cired.fr)
Date: Wed Dec 20 2000 - 00:00:47 CET
Michele Andreoli a écrit :
> Depend from the sense you give to the word "hybrid". The prolog script do
> not handle resources and configuration. It only create symlinks in the root
> filesystem located where usually a program like to find them.
>
> Example: this is a row extracted from the perl's prolog :
>
> # ln -s -f /usr/perl/CPAN /usr/lib/perl5
>
> because perl5 like to have a directory called /usr/lib/perl5/CPAN, not
> /usr/perl/CPAN.
I see. And to classify that system, I reinsist on hybrid ;-)... with the idea that
the add-on isn't only an amount of data (at install time, I mean) but also has some
functionnalities related to installation.
> To put the add-ons specific .fun on the add-on disk is not so straightforward
> as one can think.
I agree. And one can say, everything is always harder than what one thought at first
glance. In every project, and everyday life as well, it isn't possible to locate the
problems before being confronted to them and so things are always worse.
> Let me give some example: the httpd.fun, the sendmail.fun
> and other. They can work WITH and WITHOUT the SRV addon, acting
> differently in both cases. httpd.fun starts thttpd if available; otherwise
> it starts pygmy.
In that case it is simplest, maybe, as there is nothing to do.
Oh well, it gives me an idea...
Why not have the choice where to put the setup funs ? I have a really simple idea :
you put the .fun either on the first disk or in a specified directory on the addon,
like $mnt/setup.
When doing the setup, if there is no .fun the ressource is skipped (that is allready
that way, I think).
when an add-on is loaded, the following command is run
for fun in `ls $addonmountpoint/setup`; do
ln -s $fun $setup/`basename $fun`
done;
This doesn't waste much place on the first floppy, and it permits you to choose
where you put the .fun, on the add-on or the first disk. The ressource still must
appear in the setup/custom or the like directory. Note that it also could be added
in the end, if it doesn't appears, with something like
for funfile in `ls $addonmountpoint/setup`; do
fun=`basename $funfile`
ln -s $funfile $setup/$fun
$ress=`sed "s/$fun/\\\.fun\$//"`
grep "$ress" /setup/custom || echo $ress >> /setup/custom
done;
with that kind of thing, you can add add-ons from 3rd party without even bothering
putting anything in the setup dir.
It is no more than an idea thrown.
In fact I hadn't seen that point in Gerrit or Jochen's point of view. With that kind
of trick you should end up with nothing to change in the base floppy when you want
to integrate a new 3rd party add-on.
There also would be backward compatibility with the usual add-ons management way, so
that the net effect would be that you have less work.
It would be up to the maintainer of an add-on to keep it in sync with the changes in
setup or .fun scripts.
You can further suppose the add-on loading script (ie 3rdparty-add-on.fun) is taken
from the first sector of a disk with the dd trick (even if it won't work that way,
it is only an example).
The still remaining difficulty is, how will setup know that there is a from now
unknown add-on that "would like" to be loaded ?
What about a new .fun, that will be called after the add-ons ? My idea is the
following :
the ressource needs a file in /setup/store, called for example etc/addlist. In this
file there is an add-on name on each line.
the prepare section asks whether the user want to install an add-on. If yes, the
name of the add-on is extracted and put in addlist. It is that until the user says
no. A.cnf associated with this add-on it is created. And that's all, because
configure is now called, which loads the add-ons.
If this file is empty, the configure script doesn't do anything.
if the file isn't empty, the configure script, for all of the names in addlist
extracts newadd-on.fun from the first blocks and is put it in /setup/fun (or
symlinked to), and if the name of the add-on match, then the new-add-on.fun is
launched, by a "setup new-add-on". It is now loaded with LOADER and a command line
precising the offset (not currently in LOADER but easy to implement)Then the .fun
are symlinked as described above.
In the .fun of this new-add-on, the prepare section should be the following :
prompt do you want new-addon ?
And if the answer is no, then the entry in etc/addlist is removed.
That's all. Oh it is quite marmelata all what I wrote... And it will take some
place. (a .fun space in fact).
But what do you think about that stuff nevertheless ? Does it seems non sense or
ininterresting ? It seems to me to be backward compatible, and only add one
ressource with an only think to change, that is add a command line switch in LOADER
that permits to choose an offset instead of 0 used for Addons other than usr.
Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: mulinux-help@sunsite.auc.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:17 CET