Building better dotpups
Posted: Fri 15 Jul 2005, 21:30
This may be a lengthy post, as I have a few different things to say. I know that there are people more versed in making dotpups than me but I want to post a few ideas.
First off, I think that the way dotpups are currently setup is a fantastic idea. One of Puppy's goals is to be easy to understand for new users. Since many new users are coming from a Windows background they are used to installing software by clicking on intallxxx.exe where xxx is the name of the program. What I'm getting at is that the dotpup format is very easy for them to understand. Also, these dotpups have made an incredible impact on the amount of software available to use.
Pupget, on the other hand, is pure Linux. You open the program (pupget) and choose from a list of available packages. The program then downloads and installs them from an online repository. In use this is remarkably like apt-get or rpm package management. Barry has thus far made it remarkably easier to use than either of those, however. Personally I prefer the dotpups as they are more flexible. I run off the live CD and have a few roxapps that I moved to /mnt/home, leaving more space in my pup001 file. The roxapps still work and don't seem to care where they are.
What I see as the shortcoming of a lot of these dotpups is that they don't register with pupget. Barry has mentioned many times that this is an important consideration, especially if anything is installed in /usr. The main danger is that when a person upgrades to a new version of Puppy, the files will be removed by the operating system-which is doing what it is supposed to do. Obviously this is much less of an issue with a roxapp which exists completely in /my-roxapps. However, there are still reasons for registering the package.
Even with a roxapp, functionality can be greatly enhanced by placing a symlink to the executable in /usr/bin. If this is done the program can be easily called from the command line. Another benefit is that it is now easy to create a menu entry so that the program can be called from the start menu. This also makes it easier for new users to find. This has already been partly implemented by Geust Too. Some of his dotpups have an entry in the start menu if you are using his icewm package, making things really handy. If this is done, the symlink should be registered with pupget for the above mentioned reasons.
There are two more important reasons for registering the package. If a dotpup is registered it can later be removed using pupget. I've installed programs before and later spent a long time tracking down all of the files when I wanted to get rid of it. At the very least it's a good idea to provide a list of all the files in the dotpup so that the end user won't have to hunt later. Again, not much of an issue with roxapps.
One more reason I see for doing this is to use pupget to troubleshoot dependency issues. I recently made a rather large dotpup to install Cinepaint. Since I made it from the start to register with pupget, I was able to easily identify problems with the neccessary library files. Some of the files had awful names like libIlmmImf.so. Now look closely and see if you can tell the difference between the capitol i's and the lower case L's. Anyway, the program required a symlink with this name that pointed to libIlmmImf.so.2.0.1 and I was having trouble getting it typed correctly. My firs try to make a working dotpup for this was missing the symlink because it was spelled incorrectly. I used pupget to check the dependencies and it quickly found where the problem lied. As more and more complicated programs are added to Puppy this will be more of a useful tool. If you don't think that this is happening remember that Puppy 1.04 will have OpenOffice available as a pupget. Also look at Bladehunters very interesting idea for a development tools package using an /opt/tools squash filesystem.
Don't get me wrong, I want the Puppy live CD to stay small and light. But people are going to keep adding more heavyweight apps and should not be discouraged. It will make Puppy more useful than ever. I was utterly dumbfounded the first time I saw Gimp open in 2 seconds in Puppy. In most other distros this can take forever.
To illustrate how these things can be accomplished I'm paqsting a script below.
This is the dotpup.sh script that I just finished for the old patched version of Dillo that can do tabs, frames, and other neet tricks. If you follow the script you can see several key points. After the files have been untarred to the correct directories, it adds a line to alienpackages.txt which includes the neccessary info for pupget to know it's there. The files dillo_patched.files and dillo_patched.keyword were already in the tarball and don't have to be created now like pupget does.
The script then proceeds to add menu entries in the fvwm95, jwm, and icewm menus. If they're already there it's not supposed to duplicate them but I seem to have done something wrong. Update-found and fixed. Finally Dillo_patched is started. Since the tarball included an xpm that goes in /mini-icons, there will even be a Dillo icon beside Dillo_patched in the menu. I want to thank papschtroumpf as his pinstall script for betaftpd gave me the needed model to get this part working.
Please don't take any of this the wrong way because I'm not tooting my own horn here. Barry has been saying for a while that there will be more interaction between dotpup and pupget in the future. I wanted to make things cooporate now. Feel free to copy this script to use as a template if you like as it would work well with just a few modifications for other programs.
Finally, for the future here's what I'd like to see. I think pupget will always be the "official" package manager for Puppy, with dotpup being used to make just about anything under the sun work for you. I've been looking at the scripts for both pupget and dotpup to get ideas for how they can be made more cozy. I've been trying to make my own version of dotpup that would automatically put the appropriate entry into alienpackages.txt and populate the list of files. This would work for all dotpups and not require the type of code you see above, so new users could still make good dotpups like they can now. With enough work it might even be able to create an entry in the start menu. I think that this is what Barry would like to see, also. So far my script doesn't do what I want it to do, but at least I haven't broken anything yet.
I'm also following what Bladehunter has been up to with his /opt/tools development package. I particularly like the idea of a large application residing somewhere other than the ramdisk or pup001 file. This would allow access to some really heavy duty apps while leaving the core parts of Puppy small and light, just like it should be. I'm thinking of incorporating this idea to get a couple of ideas of my own off the ground.
If anyone has any further ideas or is interested in my dotpup project let me know. Of course for all I know Geust Too may already have an improvement in the works.
Nathan
First off, I think that the way dotpups are currently setup is a fantastic idea. One of Puppy's goals is to be easy to understand for new users. Since many new users are coming from a Windows background they are used to installing software by clicking on intallxxx.exe where xxx is the name of the program. What I'm getting at is that the dotpup format is very easy for them to understand. Also, these dotpups have made an incredible impact on the amount of software available to use.
Pupget, on the other hand, is pure Linux. You open the program (pupget) and choose from a list of available packages. The program then downloads and installs them from an online repository. In use this is remarkably like apt-get or rpm package management. Barry has thus far made it remarkably easier to use than either of those, however. Personally I prefer the dotpups as they are more flexible. I run off the live CD and have a few roxapps that I moved to /mnt/home, leaving more space in my pup001 file. The roxapps still work and don't seem to care where they are.
What I see as the shortcoming of a lot of these dotpups is that they don't register with pupget. Barry has mentioned many times that this is an important consideration, especially if anything is installed in /usr. The main danger is that when a person upgrades to a new version of Puppy, the files will be removed by the operating system-which is doing what it is supposed to do. Obviously this is much less of an issue with a roxapp which exists completely in /my-roxapps. However, there are still reasons for registering the package.
Even with a roxapp, functionality can be greatly enhanced by placing a symlink to the executable in /usr/bin. If this is done the program can be easily called from the command line. Another benefit is that it is now easy to create a menu entry so that the program can be called from the start menu. This also makes it easier for new users to find. This has already been partly implemented by Geust Too. Some of his dotpups have an entry in the start menu if you are using his icewm package, making things really handy. If this is done, the symlink should be registered with pupget for the above mentioned reasons.
There are two more important reasons for registering the package. If a dotpup is registered it can later be removed using pupget. I've installed programs before and later spent a long time tracking down all of the files when I wanted to get rid of it. At the very least it's a good idea to provide a list of all the files in the dotpup so that the end user won't have to hunt later. Again, not much of an issue with roxapps.
One more reason I see for doing this is to use pupget to troubleshoot dependency issues. I recently made a rather large dotpup to install Cinepaint. Since I made it from the start to register with pupget, I was able to easily identify problems with the neccessary library files. Some of the files had awful names like libIlmmImf.so. Now look closely and see if you can tell the difference between the capitol i's and the lower case L's. Anyway, the program required a symlink with this name that pointed to libIlmmImf.so.2.0.1 and I was having trouble getting it typed correctly. My firs try to make a working dotpup for this was missing the symlink because it was spelled incorrectly. I used pupget to check the dependencies and it quickly found where the problem lied. As more and more complicated programs are added to Puppy this will be more of a useful tool. If you don't think that this is happening remember that Puppy 1.04 will have OpenOffice available as a pupget. Also look at Bladehunters very interesting idea for a development tools package using an /opt/tools squash filesystem.
Don't get me wrong, I want the Puppy live CD to stay small and light. But people are going to keep adding more heavyweight apps and should not be discouraged. It will make Puppy more useful than ever. I was utterly dumbfounded the first time I saw Gimp open in 2 seconds in Puppy. In most other distros this can take forever.
To illustrate how these things can be accomplished I'm paqsting a script below.
Code: Select all
#!/bin/sh
# installs dillo_patched and registers with pupget
# dotpup made July 2005 by Nathan Fisher
# with thanks to mouldy for making it possible
# this script automatically runs after the dotpup file is unzipped
# it can rm, mv, cp files and dirs
# it can ln or rm symlinks
# it can run programs
# unzip the files using absolute paths
# paths relative to $HOME might be better
tar -xzP --no-same-owner -f dotpup.tar.gz
# registering with pupget
# dillo_patched.files & dillo_patched.keyword are included in tarball
echo '"dillo_patched" "dillo_patched: extended version of dillo" on "extended version of dillo" \' >> /root/.packages/alienpackages.txt
sleep 1
# this part of the script will register Dillo_patched in the fvwm95, jwm, and icewm menus
### register in the fvwm95 menu
# entry is placed just above smm
FVWM95RC="/root/.fvwm95rc"
if [ -f $FVWM95RC ] ; then
# this option is used to prevent the entry from going in more than once
grep "/usr/local/bin/dillo_patched" $FVWM95RC
if [ $? -ne 0 ] ;then
cp -f $FVWM95RC /tmp/DOTfvwm95.dillo_patched.backup
EDITTEXT="s/^\(.\+Exec smm\)/+ \"Dillo patched browser%dillo_patched.xpm%\" Exec exec \/usr\/local\/bin\/dillo_patched\n\1/"
sed -e "$EDITTEXT" $FVWM95RC >/tmp/dillo_patchedinstall.tmp
mv -f /tmp/dillo_patchedinstall.tmp $FVWM95RC
sleep 1
fi
fi
### register in the jwm menu
# entry is just above smm
JWMRC="/root/.jwmrc"
if [ -f $JWMRC ] ; then
# this option is used to prevent the entry from going in more than once
grep "/usr/loca/bin/dillo_patched" $JWMRC
if [ $? -ne 0 ] ;then
cp -f $JWMRC /tmp/DOTjwm.dillo_patched.backup
EDITTEXT="s/^\(.\+Program label=\"SMM email prefilter.\+$\)/<Program label=\"Dillo patched browser\" icon=\"dillo_patched.xpm\">exec \/usr\/local\/bin\/dillo_patched<\/Program>\n\1/"
sed -e "$EDITTEXT" $JWMRC >/tmp/dillo_patchedinstall.tmp
mv -f /tmp/dillo_patchedinstall.tmp $JWMRC
sleep 1
fi
fi
### register in the icewm menu
# entered just above smm
ICEWMMENU="/root/.icewm/menu"
if [ -f $ICEWMMENU ] ; then
# this option is used to prevent the entry from going in more than once
grep "/usr/local/bin/dillo_patched" $ICEWMMENU
if [ $? -ne 0 ] ;then
cp -f $ICEWMMENU /tmp/icewmmenu.dillo_patched.backup
EDITTEXT="s/^\(.\+prog \"SMM email prefilter.\+$\)/\tprog \"Dillo patched browser\" dillo_patched \/usr\/local\/bin\/dillo_patched\n\1/"
sed -e "$EDITTEXT" $ICEWMMENU >/tmp/dillo_patchedinstall.tmp
mv -f /tmp/dillo_patchedinstall.tmp $ICEWMMENU
fi
fi
# opening dillo_patched
/usr/local/bin/dillo_patched
The script then proceeds to add menu entries in the fvwm95, jwm, and icewm menus. If they're already there it's not supposed to duplicate them but I seem to have done something wrong. Update-found and fixed. Finally Dillo_patched is started. Since the tarball included an xpm that goes in /mini-icons, there will even be a Dillo icon beside Dillo_patched in the menu. I want to thank papschtroumpf as his pinstall script for betaftpd gave me the needed model to get this part working.
Please don't take any of this the wrong way because I'm not tooting my own horn here. Barry has been saying for a while that there will be more interaction between dotpup and pupget in the future. I wanted to make things cooporate now. Feel free to copy this script to use as a template if you like as it would work well with just a few modifications for other programs.
Finally, for the future here's what I'd like to see. I think pupget will always be the "official" package manager for Puppy, with dotpup being used to make just about anything under the sun work for you. I've been looking at the scripts for both pupget and dotpup to get ideas for how they can be made more cozy. I've been trying to make my own version of dotpup that would automatically put the appropriate entry into alienpackages.txt and populate the list of files. This would work for all dotpups and not require the type of code you see above, so new users could still make good dotpups like they can now. With enough work it might even be able to create an entry in the start menu. I think that this is what Barry would like to see, also. So far my script doesn't do what I want it to do, but at least I haven't broken anything yet.
I'm also following what Bladehunter has been up to with his /opt/tools development package. I particularly like the idea of a large application residing somewhere other than the ramdisk or pup001 file. This would allow access to some really heavy duty apps while leaving the core parts of Puppy small and light, just like it should be. I'm thinking of incorporating this idea to get a couple of ideas of my own off the ground.
If anyone has any further ideas or is interested in my dotpup project let me know. Of course for all I know Geust Too may already have an improvement in the works.
Nathan