From: Dumas Patrice (dumas@centre-cired.fr)
Date: Mon Nov 06 2000 - 12:30:19 CET
> >
> > 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.
>
> Do you means to separate dynamic and static info in the *.cnf pool?
> But the static part is only a little percentage: the RESOURCE variable,
> that store the basic info about resource, like "ntfs support", etc.
>
> The most import variables are ACTION= (a bad name: should be STATUS),
> and VAR_LIST.
>
> So, what is static?
IMO, static info is
RESOURCE, VAR_LIST, HIDDEN_LIST, MOD_LIST.
dynamic info is ACTION, and all the parameters.
> This is the RedHat way-of-life; so cdrom is mounted in /mnt/cdrom.
> I do not like that, sorry. I like economy.
It is not becaus RedHat do it that I think is is a good idea, but because at home
I have 7 mount points, and I prefer let only important stuff is in /. If there is
only /a, /c and /cdrom, it can get with, but if there is also /b, /loop, /burner,
/parallelDrive, and so on, I believe it becomes too much mount points in /. But it
is only my peculiar point of view.
>
> What's the problem in seeing this directories in the top hierarchy?
Again, it is my point of view, but for me the top-level directory is here to
organize the filesystem, so that every directory in the top directory refers to a
specific kind of stuff. /bin for binaries, /boot for boot stuff, /etc for config,
/mnt for mount points, /dev for devices files, /home for users'hierarchies, ... ,
and /usr and /opt are here for stuff that either doesn't fit in one category,
(especially for /opt), or (in the case of /usr) are not critical (/usr/bin for
example) or may be shared (/usr/doc). But it is true that it is a matter of point
of view ! One may dissert on the subject for hours and years... If you haven't the
same point of view than me, just throw it away ! After all you are the maintainer
of muLinux, if I want to do my own with my own muLinux with stuff organized how I
want, I just can do it. But I don't want to, as I won't be able, and you do it
better than anyone.
> I, many times, pondered on that. This script are currently in the startup
> disk because they are loaded by the /bin/setup script: the Setup script
> do not differentiate from addon and other resource.
I think you didn't understood my point of view. Well, I reread myself, it is
because I never explained it ;-). I am not arguing about the addons themselves
(like GCC, TEX, ....) but about the ressources located on the addons, like
dosemu, syslogd, nokia, and so on. I think the related dosemu.fun and nokia.cnf,
and so on could reside on the addons themselves, but not the GCC.fun, GCC.cnf that
still are on the root.gz.
[snip]
> With this solution, i can load the INFO part with a command like:
>
> dd if=/dev/fd0H1722 bs=1k count=20k | gzip -dc
> | (cd /setup/fun ; tar -xf-)
>
> After that, I have to read interpret the INFO part and load the DATA
> part:
>
> dd if=/dev/fd0H1722 skip=20k ... etc ...
That is an interresting way of doing. Then, the only information needed would be
the count information. But note also that it goes well beyond what I propose.
> A way to answer to all your
> question is: a package manager!
I don't think it is needed. The only think that is required in my proposal, is a
dependancies database located elsewhere than in the addon.tgz itself.
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