Extension loading order

Forum: myDSL Extensions (deprecated)
Topic: Extension loading order
started by: Delta-9

Posted by Delta-9 on Sep. 20 2004,14:47

Can anyone detail for me the logic with which DSL loads extensions from the root folder on a CD?

I'm working on some extensions that need to be loaded after others, and getting some curious results. I thought it was *.tar.gz first, then *.dsl and finally *.uci in a seperate step, with files in each group being loaded alphabetically by filename. However, the results I'm getting make me think that it may not be that simple.

Posted by henk1955 on Sep. 20 2004,15:29

i think its *.tar.gz then *.dsl then *.uci
each of then in alphabetical order (case sensitive)
??

Posted by Delta-9 on Sep. 20 2004,16:14

Hmm... Maybe I confused myself by changing too many variables at once. I'll experiment a little further. But, thanks for supporting my theory!

Since I live mostly in "The Wonderful World of M$", I tend to forget about case-sensitivity. Not the fact that Linux is case-sensitive, but rather just how it will effect sorting. I've always regarded it as just another way that Bill tried to sabotage compatability with the rest of the digital universe. :angry:

Posted by ke4nt1 on Sep. 20 2004,18:07

Since the filenames are just "labels" in linux,
you could temporarily rename some of your downloaded
extensions in the sort order you wish without causing any
harm to the extensions functions .
( unlike an *.exe in windows, which when renamed into an *.abc, will not run )

So you could make tham ALL .tar.gz's or .dsl's
It makes no difference to DSL or myDSL.
Then have an A.dsl , B.dsl, C.dsl, D.dsl , etc..
Or, 1-dsl-dpkg.dsl , 2-gnu-utils.dsl , 3-alsadebs.dsl , etc..

73
ke4nt

Posted by henk1955 on Sep. 20 2004,18:30

as far as i kown there is a BIG diference between *.dsl and *.tar.gz
although *.dsl a created the same way as *.tar.gz.

for *.tar.gz run ( extracts) only in the intitial minirootfs created at boot time

on the otherhand if a *.dsl is loaded some very important directories are copied to ramdisk, this is called makewriteable as it makes the cdrom "writeable" (/bin /lib /sbin /usr) this way a *.dsl can import new libs. etc

Posted by roberts on Sep. 20 2004,18:36

Your assumption and henk's post are correct. I am curious as to why the order is important. They are only loading and not running. If there are incompatible files overlaying others that would cause a problem then that needs to be brought to our attention. I believe such was the case and discovered by henk regarding gimp2.0. You can use the work around by adding a prefix to the extension name as suggested by ke4nt. But still any incompatiblies need and should be brought to our attention. You should not rename the suffix of an extension, as that could affect the proper loading of the extension.

Posted by Delta-9 on Sep. 21 2004,04:28

Thanks to all. My primary problem was that it had been too many years since I'd laid eyes on an ASCII table (combined with years of using case-ignorant M$ OSs). I've got my head on straight now, at least. Maybe... :;):

Everything I'm doing can be contained in /home, so (as I understand the extension system) should be kept as *.tar.gz, right? However, in some cases, configuration files are subsequently being overwritten by files in the .dsl when it loads. For example, I place a new theme for icewm in /home/damnsmall/.icewm/themes/keramik/ and modify the/home/damnsmall/.icewm/theme file accordingly to make it the new default. I package this as icewm-keramik.tar.gz which obviously requires icewm.dsl. But, icewm.dsl loads afterward as a .dsl and also contains a /home/damnsmall/.icewm/theme. So, it resets the default back.

I suspect that the default config in the .dsl may belong elsewhere, since duplicates found in /home usually take precedence. I'll have to check the icewm docs tomorrow. The same scenario occurs with other .dsl extensions I'm using, so I'll define them as I isolate them. Again, thanks everyone!

Posted by frans on Sep. 21 2004,07:46

if you add files or forders to /home/dsl you should add the to the filetool.sh than you can backupup and restore them

the order in wich dsl works is
1. it load all extentions
2 then it run restore

so config files and setting that are included with the extensions are overwriten with the config files you backedup
no need to make *.tar.gz and figure out the loading order let filetool.sh do the hard work for you

Posted by mikshaw on Sep. 21 2004,13:17

This assumes that the user has a partition available on which to backup and restore...just wanted to let you know that there may indeed be a need to make *.tar.gz.
In this case, one option is to make your backup settings a *.dsl rather than *.tar.gz. Since you've already mkwriteable'ed (is that a word? no, i don't think so) by loading a *.dsl, there's no advantage to using tar.gz for backups. If your backup file is named zzz.dsl, it should be the last extension loaded.

Posted by frans on Sep. 21 2004,13:42

the user MUST have a partion avalable to store his myDSL-extenstions let it be the livecd.
now if he adjust the filetool.lst with the setting he wants to keep, then do a backup targeting ramdrisk.
he gets all his setting in /ramdisk/backup.tar.gz.
copy this together with the myDSL-extensions he has to the livecd.
boot with "dsl restore=cdrom".
i think this is an easy way to presset his configuration.
still no need for makewriteable

Posted by mikshaw on Sep. 21 2004,14:16

I hadn't thought of that....so what happens is that backup.tar.gz gets copied to $HOME, overwritten in part by the icewm extension, and then re-written during restore?

Posted by frans on Sep. 21 2004,14:27

what happens is:
first myDSL-extensions are loaded. (backup.tar.gz is skiped during autoloading of extentions).
then at the end of init 5 just before bootlocal, dsl-restore is called

so first the extensions setup the default settings in home THEN restore overwrites with user settings.

Posted by Delta-9 on Sep. 21 2004,15:00

Yes, both of these suggestions will produce the desired result (tested yesterday). Funny, zzz.dsl is exactly what I used! However, I believe they merely work around some rather short-sighted design decisions in the construction of the various .dsl files which will limit their cross compatability and flexability.

I need to do some more research & testing to be sure, but I want to work within the "design plan" for DSL for the reasons that roberts cited on the prior page. I think backup/restore is really intended for non-static data on writable media. This, of course, includes config data but also requires a boot line argument. Additionally, stuff placed into backup.tar.gz is of no use to anyone else. :cool:

Posted by mikshaw on Sep. 21 2004,19:17

Quote (Guest @ Sep. 21 2004,10:27)

Why is backup.tar.gz skipped? If it's in the root of the CD, wouldn't it be loaded automatically along with *.tar.gz extensions?

Posted by henk1955 on Sep. 21 2004,19:21

if you look in /etc/init.d/dsl-config you will see it is skipped in linenr 11.

Posted by mikshaw on Sep. 21 2004,22:58

ooohh...so it's that particular filename (I'm guessing...i don't have dsl running at the moment) which is skipped intentionally? Very cool.

Posted by roberts on Sep. 22 2004,01:56

I purposely designed it that way so that the user's backup.tar.gz has final say on his system.

Posted by Delta-9 on Sep. 22 2004,12:31

As it should, of course! However, shouldn't a .tar.gz extension be able to modify the default behavior of a subsequently loaded .dsl module, at least in theory?

I'm trying to accomplish the same thing that almostX-theme.tar.gz does to fluxbox when auto-loaded from the root. The problem most likely did not occur with fluxbox, since it is already exists when .tar.gz files are loaded. I can do the same thing with xmms, which pre-exists, but not with icewm, mplayer or xine which are .dsl modules.

I'm guessing that's why icewm-blue includes icewm again instead of being just the theme.

Posted by henk1955 on Sep. 22 2004,14:55

Quote

However, shouldn't a .tar.gz extension be able to modify the default behavior of a subsequently loaded .dsl module, at least in theory?

i dont think so. extensions should be build as standalones with reasonable default.
i think its a clear patern.
1. load all the extensions
2. then use backup.tar.gz to adjust the default to your need

Quote

I'm guessing that's why icewm-blue includes icewm again instead of being just the theme.

it is very well posible to create a theme.dsl for icewm withouth including the whole icewm again. i think the icewm-blue.dsl is more of a snapshot form the builders desktop.
i just tied two options.
1. created a theme.tar.gz from my /home/dsl/.icewm/themes and have i loaded at boottime before icewm.dsl is loaded
this can be a *.tar.gz as it writes in /home

2. created a theme (1in1-xp.dsl) from /usr/share/icewm/themes and have i loaded at boottime before icewm.dsl is loaded (just because for the alphabetic order)
this must be a *.dsl as it writes in /usr

Posted by Delta-9 on Sep. 22 2004,16:42

There will always be more than one way to skin a cat, but this is beside the point.

Quote

1. created a theme.tar.gz from my /home/dsl/.icewm/themes and have i loaded at boottime before icewm.dsl is loaded
this can be a *.tar.gz as it writes in /home

Yes, but try to make it the new default theme for icewm (without using restore) like almostX for fluxbox does. Anything can be set as default using restore, but then your backup.tar.gz is dependant on certain extension modules being loaded. I have found that this can have other unforseen consequences so I don't use it at all... yet.

Quote

2. created a theme (1in1-xp.dsl) from /usr/share/icewm/themes and have i loaded at boottime before icewm.dsl is loaded (just because for the alphabetic order)
this must be a *.dsl as it writes in /usr

Thanks, this illustrates the problem pretty well. According to the IceWM documentation (< IceWM Manual >) this is improper. A user's personal add-on themes belong in $HOME/.icewm/themes whereas only the default built-in themes should be found in /usr/share/icewm/themes OR /usr/local/share/icewm/themes. I had to move some of the ones I'm working with to $HOME/.icewm so I was aware that not everyone "plays by the rules." But breaking the rules in this way can make your theme incompatible with later versions of IceWM and/or other themes.

In essence, this is the problem, just in reverse. The default settings in icewm.dsl were placed in $HOME/.icewm, instead of /usr/share/icewm where they belong. If moved, and the .dsl is rebuilt, everything will work as it should. I have personally verified this only with icewm-blue at this point, still need to test the base version.

Again, thanks for the feedback! Hopefully, you're helping me to clarify the issue as I see it.