cross-compatibility & overwriting directories

Forum: myDSL Extensions (deprecated)
Topic: cross-compatibility & overwriting directories
started by: clacker

Posted by clacker on Aug. 04 2004,12:59

I noticed many of the DSLs in the library now show the line in their info file:

Rebuilt for cross-compat - Removed dirs & overwriting libs

What exactly did you do to make them more compatible? How did you find which directories and libs were overwriting?

Posted by ke4nt1 on Aug. 04 2004,13:57

clacker,

Those notes are as much for my own good as they are for the extension..

Even if you were to go thru the steps I do to make an extension, I would
do them again anyway just to be sure....

During this transition phase of switching from "damnsmall" to "dsl" as the
username, I've had to use certain syntax in the tars to make sure they focus
on the uid/gid, and not the username.
Mainly --no-recursion and --numeric-owner switches in the tar commands.

The notes " rebuilt for cross-compat" is simply a note to me and the DSL staff
that this extension has been retarred/gzipped with that in mind.
This assures everyone that this will work with the username "dsl" for both
the 0.7.1 and later series, as well as the 0.8 in testing.

Then we, and you, know that if any issues arise in using the extension,
it's not due to the username change...

As far as the overwriting libs, what I'm seeing is that many contribs are
overwriting the exact same libs that are included in the base DSL...
This just adds weight to the extension, and opens up more of the system
to the ramspace, eating more memory...

In other cases, some extensions are actually overwriting the base libs
with upgraded versions...

While this may have been what was available at the time the app was compiled
and built originally, I find that in most cases, the apps runs fine with the
older version already present in DSL...again , saving precious weight and memory...

Sometimes, the extension overwrites libs that are REQUIRED by other apps.
That's the case where you install a new app that works fine, but after using it,
something else on your system is hosed...

In this case, if the app won't work with the older version of the lib, I may
choose to drop this from the repository stock, as it will only corrupt the
DSL base system, and create lots of traffic for us, and havoc on the end-users systems.
Again, this is only if the app causes troubles... Very few have displayed this
behavior, but it has happened...
So far I've caught or fixed the majority of them,
thanks to good feedback by the DSL staff and the userbase...

But new extensions are arriving every day ... ( suspense music from movie "JAWS" in background for effect...)

Gots to keep an' eye out for those pesky libs !!

yuk, yuk, yuk

73
ke4nt

Posted by clacker on Aug. 04 2004,19:25

Ke4nt1, how do you check for the overwrites? Is it a tar switch, or is there some other way to see it happen?

I'll add the --no-recursion and --numeric-owner switches to my own copy of deb2dsl for my own sake.

Posted by ke4nt1 on Aug. 05 2004,04:52

I do it the old-fashioned way...eyeballs and (ahem) emelfm...

I start with a pristine LiveCD bootup, no mydsl or restores..
No gnu-utils, dsl-dpkg, or any extensions loaded... clean and pristine...

When checking the contribs,
1. I have to make a file list to edit for the retarring...
2. I have to untar the package to look at the owners/perms...

I start in a shell as root, and open an emelfm in the background...
I usually make a "work" directory e.g. "/home/dsl/work" to do all of this in...

I'll use emelfm to look around in the files for executables, skins, themes, etc...
I'll also look at the ~/work/usr/lib dirs and compare it to the base /usr/lib dirs...
Here's where I'll catch the ones that overwrite the stock collection.
If they match EXACTLY, I'll usually pull them out of my filelist..
In some cases, I'll also pull them out if their simply a few minor versions apart.
If the app fails later, it's easy to add them back in..

Study the file structure, and you'll see where the app expects to find things...
Make a mental note of the /usr/lib/menu, /usr/share/doc, and the README's...
You'll pull all these out later to save precious ramspace and fileweight...

I'll use the root shell to look at all the owners/permissions of the files...
Lots of " ls -al " " ls-alR " and " ls -alR | more" - just pokin around in it ...
Frequently, I find all the perms are root.root or dsl.staff... no good...
I change them to match the pristine DSL .iso e.g...
/etc = root.root
/usr = root.root
/home/* = dsl.staff
/tmp/* = dsl.staff
/opt = root.root (usually)
You get the idea...
Perms should be chmod 644 or -rw-r--r-- for the icons, links, and menus,
and should be owned by dsl.staff...
Otherwise, you get the cranky desktop behavior... :angry:

Then onto the filelist...
Here is where I remove all those nasty DIRECTORIES that get in the tars.
Unless they are orphaned, and NOT in the base system, I remove them all...
Here's a short example..
/usr
/usr/bin
/usr/bin/xbubble
/usr/share/xbubble/
/usr/share/xbubble/README
/usr/share/xbubble/highscores/
/usr/share/xbubble/themes/
/usr/share/xbubble/themes/candy.gif

The ONLY lines I would leave here are ...
/usr/bin/xbubble <-- the exec.
/usr/bin/xbubble/highscores/ <-- orphan dir
/usr/bin/xbubble/themes/candy.gif <-- data file

The rest are useless deadweight...
The /usr and /usr/bin are DANGEROUS, as your OVERWRITING base dirs...
Bad puddy tat...

Also remember to remove any lines of libs or files you pulled,
or changes you made to the filenames. e.g. /home/damnsmall to /home/dsl etc...
You don't have to remove any files in the work directory that you don't want to keep...
The filelist will cull those out for you...
You DO have to rename files and dirs that were changed in the filelist, and vica-versa...

OK, so you've checked your file system for bad files, perms, owners, etc..
Give it a once over again, and check the .lnk files and the menu files
Open them up in scite, and look at the lines, make sure the paths are correct...
LF's are there, and check the owners/perms once again if you save after making corrections...

Then it's time to zip it back up...
" tar -T filelist.txt --no-recursion --numeric-owner -cvf- | gzip > filename.dsl "
Make the md5...
" md5sum filename.dsl > filename.dsl.md5.txt "

Now is a good time to copy/backup the work dir to another more permanent area -
HD , usb key, net share, etc... just in case.

Then it's testing time! Your already in a pristine bootup of DSL, so open up
a emelfm as user dsl ( from the desktop ) , and use the mydsl button to run it.

If you have troubles, your work area is still there, and if you HAVE to reboot...
( which is NOT a good sign

)
Your work area is easy to restore, and your back in business...

Open up a root shell, and open emelfm in the background... yadayadyada..

Good Luck...

73
ke4nt

Posted by nucpc on Aug. 05 2004,12:57

Just a quick query on the directories issue - although really more a UNIX
question - their appearance in the tar list is, yep, useless for sure, but
"dangerous"? "Overwriting" ? Really?

This is only a query though, I think you're doing an absolutely incredible
job ke4nt and improvements to the repository, thanks to you, are great.
And of course useless things in dsl's should come out........

All the best.

Posted by mikshaw on Aug. 05 2004,14:08

yes, really truly-fully.
The most obvious trouble I'd experienced was with all files in a .dsl, including icon and menu item, being owned by root.root. The menu is rebuilt each time an extension is installed, and what you end up with is a menu owned by root.root instead of dsl.staff

This applies the other way around as well. If you have system directories in an extension owned by dsl.staff, they'll replace the directories owned by root.root. Oops...your security just fell through the floor.

Posted by nucpc on Aug. 05 2004,15:23

Milkshaw, I see your point in first paragraph, thanks.