From: Dumas Patrice (dumas@centre-cired.fr)
Date: Fri Nov 03 2000 - 16:59:59 CET
Michele Andreoli a écrit :
> Hello,
>
> It's the time to improve the the 'client side' in muLinux.
> It is better to split the basic functions in muLinux in two
> parts: server and workstation.
I also think it is a good idea.
I have comment about another thing. Maybe you should take advantage of that
change to remove any link between any add-on and /usr/local. I don't know if
it is only me, but I like to have that directory to put things I have done
myself. It is more important for hd based muLinux, but it is (for me) a
feaure that could be interesting. Oh maybe, I am too conservative, I also
shoud use every other directory ;-).
Well, as you are asking for conceptual question, I have 3 "conceptual"
proposals.
1) I have remarked that there was 2 kinds of informations in the .cnf files.
One is about the values stored, the other is the values stored. So maybe it
would be cleaner to have the information about the storage put in another
location, for example in the corresponding .fun, so that stuff that can have
the values modified is apart from stuff that don't have to be modified. It
leads to another benefit, that is the information that doesn't change isn't
duplicated anymore, so this will save space in the /startup files, and maybe
it would become possible to store 2 different profiles on the floppy.
2) I think that /a, /c, /cdrom should be moved to /mnt (for example) so that
automatic writing in /etc/fstab, for the kind of "automatic" mounting that is
done should be expanded without overcrowding the / directory. For example, I
have a mount point for loop (/mnt/loop), a mount point for 2 cdroms drives
(one being a burner), for 2 floppy drives, my dos drive, a linux partition,
an external hard drive that goes in the parallel port. I don't know if
muLinux is going to support all these devices, but it allready support some,
so for the scalability, I advocate /a,/c and /cdrom to be placed in another
directory that /. And also maybe /startup, (but this point isn't as clear
IMO, as /startup is really specific to muLinux).
3) I haven't dug much in the scripts to know more about this, as I have never
really looked at add-ons and the way they are handled, but I don't like the
fact that .fun related to add-ons are located on the root floppy. I think it
would be better if they were with the add-on, so that it would save space on
the root floppy, but also be conceptually more clear (IMO).
I have seen some objections, that I try to overcome :
Problem :
If a .fun requires something, it has to be explicitely stated out of the
add-on, so that it is skipped if the add-on isn't present. but the require
section is in the .fun... One way would be to specify with another syntax
than a shell-script function the dependancies (a rpm database, maybe ;-).
solution :
Without joking, maybe it would be possible to have in the .cnf variables like
REQUIRE="/usr/bin/pipo /usr/tex/popi"
ADDON="EXT"
to say which programm and addon a .fun require.
Problem :
Implicitly, I am saying that the .cnf should reside in the root floppy,
because they are required for the dependancies checking. This would be very
strange. Why put the .fun in the add-ons and the .cnf not ?
Solution :
I see a way to overcome that problem, namely to put the information about the
requirements in a file that is not a .cnf nor the .fun. In custom, for
example, there should be something like
usr
syslog /usr/ext/syslogd
...
To say that syslog requires /usr/ext/syslogd tu run.
This kind of configuration file would require /bin/setup to be modified to
hold that kind of parsing. I can do that, if it seems an interresting idea.
/bin/setup should also be changed, so that if a .fun isn't found in /setup,
it searches in $ADDONMOUNTPOINT/setup/fun.
What do you all think about all that ?
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:16 CET