Filelist w/ .dsl and .tar.gz packages to uninstallForum: DSL Ideas and Suggestions Topic: Filelist w/ .dsl and .tar.gz packages to uninstall started by: drj Posted by drj on June 24 2005,13:02
It would be nice to include a filelist or even uninstall.sh with .dsl and .tar.gz packages, so that people could remove appl cleanly, only for applications, not for base sys libriaries
Posted by mikshaw on June 24 2005,13:58
This could be useful, although a few things come to my mind concerning why this isn't done....1) myDSL applications are made primarily for liveCD or other compressed setup, such as frugal. In this case uninstall is usually unnecessary, since a reboot is all that is needed to restore the system's original state. Personally I can't see too many situations where one would have the need to uninstall individual apps in this type of setup (not saying the situation doesn't exist, just that it's uncommon). For a harddrive installation, it is recommended that you use deb packages or source installs rather than myDSL. 2) Making this kind of change would require rebuilding the whole myDSL system, possibly including all myDSL apps already made. Perhaps it is not worth the time and effort required to implement this feature. 3) There are some .dsl packages which overwrite files in the original DSL system. In order to prevent the removal of these files during uninstall would require extra work for both the creator of the package and for the Keeper of the myDSL Archive (ke4nt). It may be a small thing, but i could see it still causing problems. 4) The number of .uci packages is steadily growing. I see a future in which all myDSL packages are mountable and umountable, eliminating the need for an uninstall. Posted by yyyc514 on Sep. 02 2005,15:40
1. Agreed 2. See the debian package checkinstall or watch-install or something like that... it's possible to "watch" the installs and build a list of files ourselves without adding to the work of package maintainers. 3. Yes, this is a sticky corner case. 4. I honestly don't know about this... involves a bunch of wrappers or recompiles of apps... OR post-install scripts... I think a .UCI mounted in /opt but with soft links into the rest of the filesystem would be a great compromise, but not possible until we have some sort of post-install script support. Posted by mikshaw on Sep. 02 2005,19:38
One way around the wrapper situation would be to utilize /opt/lib and /opt/bin directories in the base system, where symlinks could be added when mounted, and removed on unmount (similar to the add and remove of icons and menu items).But personally i don't really see that compiling a program to run in /opt is much more difficult than building a .dsl from a .deb, and that extra work is outweighed by the added ability to more easily strip down the program and customize it for use in DSL. Posted by ke4nt1 on Sep. 02 2005,20:15
The /opt/bin and /opt/lib option has been discussed before.But there are still some challenges , even with that in use. Depending on the program, some applications during the duration of their execution , STILL insist of finding needed things in certain locations.. Recompiling would be the best way to solve this, if your app allows the use of certain compile-time switches.. Truly, the wrappers seem to do a fine job for most of the binary contributions I see submitted, depending on the apps needs. A post-install, and post-uninstall script would seem unnecessary, if the extension and application is assembled and compiled properly.. Any configuration needs can be handled within the wrapper at execution time.. Since DSL doesn't allow custom code in the extensions, this seems kinda moot anyway ( excepting the wrappers ) User created scripts and executables make me nervous, anyway, from a support and/or 'source code available' point of view.. 73 ke4nt Posted by mikshaw on Sep. 02 2005,20:24
As far as customizing, i was talking about compile-time options rather than changes to the source code. For example, a pre-compiled application might require a different version of a lib found in DSL. As far as I know the only way to deal with this is to include the redundant library in the package. Usually compile-time options will allow you to specify what lib to use...if the program will still work with the different version, you've saved yourself some filesize. You can sometimes also disable the use of some libs when compiling, to prevent the need for stuff not needed or available in DSL. Posted by yyyc514 on Sep. 02 2005,20:55
Sure... easy for DidiWiki maybe... but XFCE... with many dependencies and 20 odd different modules to be compiled in a certain order... not saying it's "hard" once you get down to it and have some groove going, but I know it was sure faster to build an XFCE package by extracting 20 debs that aptitude told me were required and removing extaneous files than by compiling XFCE by hand... Different constraints for different people... dial-up, knowledge, processor speed, any number of factors that might make compiling from scratch a real headache for some. Just explaining why I don't like that stock answer "source is so easy". :-) Posted by yyyc514 on Sep. 02 2005,21:06
I don't know what the /opt/bin and /opt/lib discussion is about but my thought is to extract an entire non-recompiled UCI into say /opt/package/root... and under root you would find bin, etc, lib, usr etc... then a post instal script soft links the correct locations in the filesystem to the /opt locations... doesn't matter if the program is looking in certain locations, the files will be there because they will be linked...
This is hard for XFCE, where my goal is for it to be installed on a CD and to automatically boot, replacing Fluxbox... to do that it replaces .xinitrc in /home/dsl... if there was a postinstall script I could warn the user, make a backup (my preference), ask a question, etc... that's currently impossible... either it cannot be automated and the user has to do something manually or you simply overwrite the .xinitrc... a post-install script would provide some much better options. I've even thought of creating a DSL just to add post-install script functionality to DSL... does that mean I'd be viewed as an evil child? I'm confused as to why a post-install script is any less secure than a wrapper if someone is theoretically auditting such things in the first place...
Second time I've heard this... what does this mean exactly? Is there a written policy somewhere explaining practical application?
I think a policy not unlike Debian's (though I claim to be no Debian policy expert) requiriing certain licensing and source code availability isn't bad at all... I wouldn't want some blackbox code running either... but if it's plain text... or if it's compiled code with available source... I don't see such a problem. And the fact is someone submitting any package that includes binary files and you have not built it from source yourself... how do you know anything about that package? My XFCE package could format your hard drive after 30 days (rest assured, it does not)... unless (like Debian) you start with pristine source, a small patch, and do the compile yourself you're still open to all sorts of security breaches. Just my $0.02. Posted by mikshaw on Sep. 03 2005,02:52
I completely agree with that last bit....it would be very easy to just say it was an official debian package converted to a dsl, when in reality it was modified source and compiled into a dsl package. In addition to this, there is no assurance that it would be taken from an "official" debian package anyway....just like there are myDSL packages available that are not a part of the official repository. I guess what it comes down to is trust, because there's no way you can be 100% sure unless you take the time to explore every function and feature of every dsl package....an impossible task, especially for one person.For the post-install script, while it would be more convenient for the maintainer of the package, there is NOTHING you can do with a post-install script that you can't do with a wrapper....they are both shell scripts which run prior to running the program, so there is essentially no difference. The only difference I can see is that with a wrapper you would need to first check whether or not the commands have already run to avoid redundancy and possible collisions. Posted by yyyc514 on Sep. 03 2005,04:47
Except for backing up .xinitrc before replacing it... you fail to acknowledge my one valid example... I'm sure there are others, just I haven't got to them yet. :-) Posted by mikshaw on 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. Posted by yyyc514 on 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. :-) Posted by friedgold on 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. Posted by mikshaw on 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. Posted by cbagger01 on 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. Posted by mikshaw on Sep. 05 2005,01:10
Doing it that way would be good for people like me who are very concerned about programs that overwrite personal files....AS LONG AS the script is run prior to dsl_restore (S49). Although in order to deal with it personally I'd still have to switch to using the backup/restore feature rather than storing my configs in a myDSL extension...not a big issue.
Posted by cbagger01 on Sep. 05 2005,15:05
As long as you name the symlink S48_blahblah or lower, this should not be a problem.
|