iB::Topic::Filelist w/ .dsl and .tar.gz packages to uninstall

	Damn Small Linux :: Damn Small Linux Board The DSL Forums

» Welcome Guest
[ Log In :: Register ]

Damn Small Linux Board » Damn Small Linux » DSL Ideas and Suggestions » Filelist w/ .dsl and .tar.gz packages to uninstall

		Mini-ITX Boards Sale, Fanless BareBones Mini-ITX, Bootable 1G DSL USBs, 533MHz Fanless PC <-- SALE $200 each!
		Get The Official Damn Small Linux Book. DSL Market , Great VPS hosting provided by Tektonic

Pages: (4) </ 1 2 [3] 4 >/

[ Track this topic :: Email this topic :: Print this topic ]

Topic: Filelist w/ .dsl and .tar.gz packages to uninstall

< Next Oldest | Next Newest >

mikshaw

Group: Members
Posts: 4856
Joined: July 2004

Posted: Sep. 03 2005,05:13

That would be very easy to do with a wrapper. One common method of setting up an environment to run a program is to check for the existence or nonexistence of a specific "first_run" file or keyword in a file. If it's found (or not found, depending on the developer's preference), then a setup script (equivalent to the post-install script) is run and the first_run object is removed (or created) so that the setup script is not run again the next time the wrapper is run.

Seriously, a post-install script is a shell script, same as a wrapper....all the same commands apply. The only difference is when it is done.

--------------
http://www.tldp.org/LDP/intro-linux/html/index.html

yyyc514

Group: Members
Posts: 41
Joined: Aug. 2005

Posted: Sep. 03 2005,05:23

If i want to have a .DSL that can simply be copied to a remastered CD with no other changes and change DSL's default env to flux to XFCE... I cannot do that... without overwriting the users .xinitrc without asking...

If I wish to automatically be the new window manager there is no context for a wrapper... for the file i want to replace is the wrapper that would replace the file... its becomes a viscious circle that is unresolvable given you want a 100% automated install and the possibility of a backup.

Maybe these requirements are unreasonable, but in this case wrapper doesn't cut it. :-)

friedgold

Group: Members
Posts: 122
Joined: Mar. 2005

Posted: Sep. 03 2005,13:54

As far as I can see the limitations of using wrappers are

- They are run multiple times, not just the first time the program is installed/run.

As mikshaw points out it is possible to work around this using a first_run file.

- Wrappers are only run when a program is loaded. This is a problem for things like device drivers/libraries/etc where there is no program to load.

It is possible to get around this by including a startup script in the extension which sets everything up (for example see the alsa extension). However this won't work for extensions loaded after booting DSL.

So I agree that it is possible to achieve most things only using wrappers. However I still think that install scripts would be a good idea. They are simply the most natural solution to some of the issues associated with packaging extensions, where as the use of wrappers is a kludgey solution. I'm not sure I understand the argument against using install scripts. It seems to me it would be fairly easy to add to the mydsl system. After unpacking the extension just check for the existance of, say, /var/mydsl/scripts/$PACKAGE_NAME, and if it exists run it. Then if you want to include a install script you'd just include it as /var/mydsl/scripts/$PACKAGE_NAME.

Also I don't see how using a install script makes an extension any harder to check for problems before adding to the repository, since the alternative (using a wrapper) is a shell script too.

mikshaw

Group: Members
Posts: 4856
Joined: July 2004

Posted: Sep. 03 2005,14:08

Yeah, I get what you're saying. With a window manager extension, there is no user interaction in DSL *if* the goal is to make it the default window manager without the user doing *anything*. But as I said to you on irc, I think it is improper behavior for any program, especially an add-on program, to be built to make assumptions like that, particularly in an operating system like Linux that is all about giving the user choice. Just because I installed a program, it doesn't mean i want to use it right away. Assuming otherwise just reeks of Microsoft.

Maybe most users would want that, as you said....i don't know. I know i wouldn't appreciate it myself. A more appropriate course of action, in my opinion, is to add instructions in the info file for those who want to make xfce their default wm. It's a simple task even for people who are slaves to wimp....everything necessary can be accomplished in DSL through gui interface.

Perhaps we could consider something like XwmMenu, a small (26k) program that gives the user a GUI selector with which to choose what program to start when they enter X. To make that automated (if that's the goal), A wrapper might need to built for it that would create an ini file from available window managers. Of course, if it were to solve your xinitrc problem XwmMenu would already need to be inserted in xinitrc...so the cycle continues....

EDIT: okay, so not EVERYTHING can be accomplished without a post-install script. I didn't think about other programs that are started with no user interaction. Still, as i said, just because you install something it doesn't mean you want to use it right away...and if you do then there is /opt/bootlocal.sh, $HOME/.bash_profile, and $HOME/.xinitrc that you can edit and backup. It's often a lot easier to make a change than it is to undo changes that are made for you.

--------------
http://www.tldp.org/LDP/intro-linux/html/index.html

cbagger01

Group: Members
Posts: 4264
Joined: Oct. 2003

Posted: Sep. 04 2005,21:27

If the goal is to execute a script automatically upon bootup from a livecd with the extension installed in the root directory, the solution already exists.

Like was said earlier, you can simply symlink your wrapper into the appropraite /etc rc init system folder. Take a close look at the alsadebs.dsl extension for a good example.

Then your script can backup the user's original xinitrc and then copy YOUR xinit.xfce file over to replace the xinitrc.

If there is concern about doing this automatically, the solution also exists.

Simply add a custom "cheatcode" for this extension. If the cheatcode is not present in the /proc/cmdline then DON'T automatically replace the users .xinitrc

IE:

desktop=xfce

As part of your wrapper script, you look for this cheatcode and automatically replace the user's .xinitrc only if it is present.

16 replies since June 24 2005,13:02

< Next Oldest | Next Newest >

[ Track this topic :: Email this topic :: Print this topic ]

Pages: (4) </ 1 2 [3] 4 >/

Damn Small Linux Board » Damn Small Linux » DSL Ideas and Suggestions » Filelist w/ .dsl and .tar.gz packages to uninstall