How far can I go?

aKzenT · 02-01-2005, 10:00 AM

I wonder how far I can go with customizing my LFS system. I already build my own LFS, but I want something even more personal and unique

For example:

I hate the linux directory structure (don't flame me):

What if I choose to have all system stuff in a directory /system all programs in /apps all libs in /libs and instead of /etc /system/config?

I think this would produce much source code changes to change all harcoded stuff, but I think a lot of these things could be made automatic with utils like sed.

Is this possible? Anyone tried this so far? Where can I find help?

Thanks!

320mb · 02-01-2005, 10:31 AM

the directory structure is standardized.........changing it around
would only break your system............

Filesystem Hierarchy Standard:
http://www.pathname.com/fhs/

aKzenT · 02-01-2005, 05:46 PM

I know that this is a standard and normally I like standards very much, but this time I don't and I'm only wondering if it might be possible, even if it is dangerous.

I think LFS is about building "your own" system. If I do everything "normal" it would be just "the LFS-distro" and probably much less fun

crash3k · 02-02-2005, 03:34 PM

I agree, would be an interesting experiment, if you try it, lemme know how it goes..

sharky · 02-11-2005, 12:39 AM

What happens when you install software? If system info is not where configure expects it to be then will the install work? This is just one possible issue that comes to mind. There could be numerous other problems. I suspect 320mb is correct.

Regards,

slakmagik · 02-11-2005, 12:58 AM

Well, as far as the LFS filesystem goes, you can junk quite a bit of it. I like the *idea* of the FHS, but it's completely ridiculous in fact. Ain't nothing *looking* for a /media or a /srv and so on. You can junk those. You can junk /opt in most cases. At least, I've deleted mine from Slack. Mozilla goes in /usr or $HOME or wherever I want and KDE goes in /dev/null.

Just keep your 'tools' directory and the partition around and play with it. If you break it, just start over from there rather than the beginning. I agree - have fun!

-- Oh, as far as getting really weird with the dir structure (I like the *nix dir structure - just not the goofball accretions on it - well, I like a subset of it - the overall concept of it) check out stuff like - I think it's called 'GoboLinux' r something - and see about implementing something like that there. Maybe check out some of the stuff the developer of ROX (Thomas Leonard) has written. I don't go for that myself, but it might give you some ideas.

sharky · 02-11-2005, 08:09 AM

The FHS is arbitrary at best. But there are some things that can't be easily moved. Is it possible to take everything in /etc and put it in /system? Can /usr/lib, /lib and /usr/X11R6/lib all be combined into /lib ? The short answer is no. But maybe it's not impossible.

Having said that it would be interesting to see how far aKzenT can go.

Later,

hatchetman82 · 02-11-2005, 11:50 PM

just a footnote :
gobolinux is a linux distro that essentially implemented what you suggested (they also state they started from an LFS build and worked up to where they are today) - but there's a catch.
you cant truly rid yourself of the standard structure since a lot of programs have hard-coded paths. what gobo did was store all the files in their own (more reasonable, in my opinion) directory structure, and then create the standard directory structure as symlinks to the new directories (so as not to break hardwired code).
they also have an optional kernel patch to hide those symlinks from the user for asthetic reasons.

aKzenT · 02-12-2005, 09:20 PM

I also thought about symlinks, but I really don't want to see these "wrong" directories. I will do this project if I find "some" time. Probably not in the next weeks. I think a lot of the hardcoded paths could be simply replaced by something new (sed etc.).

Thank you for the Distro-Names. I will take a look at them today.

Maybe LFS is too big to start from... A small bootable linux system with only the absolutely minimum could be a better start.

edit: sorry I did not read the kernel patch-thing... That's interesting!

Thanks,
Thomas Krause

aKzenT · 02-12-2005, 10:06 PM

Here is an idea of how I want the directory tree to be:

Code:

/
    /system   #System-Files
        /devices   #Devices
        /drivers   #Driver-Modules
        /config   #global configuration settings (/etc)
        /boot    #bootloader, kernel, lilo, grub, etc. (/boot)
    /users
        /(username)    #everything related to this particular user
            /applications    #hard links to applications that are enabled for this use
                /(application)    #the application
            /data    #user data (user stuff)
            /documents     #user documents
            /config    #application configuration data for this user
                /(application) #the application config
    /applications    #actual application store, where the hardlinks are pointed to
        /(application)    #the binary application and hardlinks to used libraries
    /libraries    #libraries, that are installed on this machine
        /(library)    #an installed library

Note that every library and application has its own directory. Essential tools like "ls" could be symlinked to /system/tools or so. Every dynamically linked library an application needs is symlinked into the application's directory. Every user has it's own directory tree with his own applications. Normal users should only have there own directory tree accessible. Configuration data for applications are stored per user whenever possible(/config) or if not possible or wished directly in the application's directory.

What do you think about it?

It's a little of windows and linux together I believe.

Thomas Krause

slakmagik · 02-12-2005, 10:36 PM

Pretty nice. But where are mount points, variable data, the GUI, and so on? And that would make it difficult to partition. And I see system apps and libs and disposable user apps and libs as distinct. I think /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /opt/foo/bin, and so on might be pushing it, but still, some distinction.

The main thing I'd like is to have ~/.etc and having anyone who wrote anything in$HOME and outside ~/.etc shot. Or at least, as is, to have everyone who writes something to my $HOME that isn't a dotfile shot, anyway. And I say '.etc' like etc, but since we're dreaming, let's change it to 'rc' or 'cfg' or something. It used to be a truly 'etc' mess but it's been cleaned up to be mostly configs.

And, as I say, the filesystem's literally a tree - an old overgrown tree. Just needs pruning, but it's a good tree. These new growths like /media and /srv are growing wild and even the older parts are sometimes too thick. I'd also like it to be a rule that if you've got more than one dotfile, you have a dotdir. If you only have one dotfile, you *don't* have a dotdir.

And all the virtual filesystems like udev-related dirs and proc and so on all need to be collapsed into a $VIRDIR with subdirectories under that.

And so on.

jobesd · 02-15-2005, 03:48 PM

you wouldn't need seperate partitions. make 1 partition.

the only thing I would start with the folder named system instead of usr like you where building a tools dir
use the --prefix=/system on all the basic packages and see if you could get a basic LFS system to boot.

as fara as users I would just rename the /home to /users
and for apps. I would put all servers and programs there compiled in thier own dirs

example:

/applications
/applications/Desktop #all desktop applications
/applications/Desktop/kde
/applications/Desktop/openoffice
.etc
/applications/Servers #all server applications
/applications/Servers/apache
/applications/Servers/mysql
.etc

you would have to change stuff like this
for example: sysvinit src's "paths.h"

Code:

/*
 * paths.h	Paths of files that init and related utilities need.
 *
 * Version:	@(#) paths.h 2.84 27-Nov-2001
 *
 * Author:	Miquel van Smoorenburg, <miquels@cistron.nl>
 *
 *		This file is part of the sysvinit suite,
 *		Copyright 1991-2001 Miquel van Smoorenburg.
 *
 *		This program is free software; you can redistribute it and/or
 *		modify it under the terms of the GNU General Public License
 *		as published by the Free Software Foundation; either version
 *		2 of the License, or (at your option) any later version.
 */
#define VT_MASTER	                "/dev/tty0" to  /system/devices/tty0	/* Virtual console master */
#define CONSOLE		"/dev/console"		                /* Logical system console */
#define SECURETTY	                "/etc/securetty"	                                /* List of root terminals */
#define SDALLOW		"/etc/shutdown.allow"	                 /* Users allowed to shutdown */
#define INITTAB		"/etc/inittab"		                 /* Location of inittab */
#define INIT		"/sbin/init"		                 /* Location of init itself. */
#define NOLOGIN		"/etc/nologin"		                 /* Stop user logging in. */
#define FASTBOOT	                "/fastboot"		                 /* Enable fast boot. */
#define FORCEFSCK	                "/forcefsck"		                 /* Force fsck on boot */
#define SDPID		"/var/run/shutdown.pid"	                 /* PID of shutdown program */
#define SHELL		"/bin/sh"		                                 /* Default shell */
#define INITSCRIPT	                 "/etc/initscript"	                                  /* Initscript. */
#define PWRSTAT		 "/etc/powerstatus"	                                  /* COMPAT: SIGPWR reason (OK/BAD) */

#if 0
#define INITLVL		"/etc/initrunlvl"	/* COMPAT: New runlevel */
#define INITLVL2	                "/var/log/initrunlvl"	/* COMPAT: New runlevel */
				/* Note: INITLVL2 definition needs INITLVL */
#define HALTSCRIPT1	"/etc/init.d/halt"	/* Called by "fast" shutdown */
#define HALTSCRIPT2	"/etc/rc.d/rc.0"	/* Called by "fast" shutdown */
#define REBOOTSCRIPT1	"/etc/init.d/reboot"	/* Ditto. */
#define REBOOTSCRIPT2	"/etc/rc.d/rc.6"	/* Ditto. */
#endif


then you would have to change all the mount points in the bootup scripts
for example:

/system/<the bin dir or if you put all binaries in a dir that dir>/mount -t devfs none /system/devices

or where that folder will reside.

I don't know what can or can't be changed but It would be interesting.
jobesd

hatchetman82 · 02-16-2005, 09:52 PM

instead of re-wiring all the apps, a better idea would be to re-write their makefiles or whatnot to take these directories as parameters. then you wouldnt need to re-wire per directory structure

aKzenT · 02-17-2005, 01:32 AM

This would be the best, but also the most time consuming.

Maybe you could store the essential directories in environment variables. Like CONFIG_DIR=/system/config or /etc. Then you could change all makefiles to use these directories (maybe automated with sed or so). But the problem would not be solved completely. For example I want every library to be in it's own directory, regardless of how essential they are. So every Package would need it's own LIBDIR.

A small script could do wonders, which would change all /lib references to sthg. like /libraries/programname in the makefile/source files and also add the path for the dynamic linker.

Thomas Krause

slakmagik · 02-17-2005, 01:39 AM

Part of the reason most implementations involve screwing around with the system after the fact, such as with symlinks is that trying to use environmental variables or any sort of scripting would be between mind-blowingly-complex and impossible because there's approximately 957 build methods in use. *Most* things use the predominant ./configure && make && make install and have a generated and reasonably consistent set of variables, but things differ subtly even there and there are many packages that use other methods entirely.

Writing *normal* build scripts is a pain. Trying to get them to jump through hoops at the same time would be quite a feat.