Puppy Linux Mini How-to

An easy way to copy path names to dotpup.sh: hold ctrl key and click a file or dir will copy the path to clipboard.
Middle-click to paste it into dotpup.sh script.

To see the error message generated when creating your DotPup, you can run make-tar, dotpup.sh and make-pup from the commandline (e.g, ./make-tar).

Do not create DotPup that put files in the /usr directory unless they are registered with PupGet. Files in /usr will be overwritten when Puppy is upgraded to a new version if they are not registered with PupGet. Install files somewhere else (e.g., in my-roxapp or in
my-applications) and make a symlink or 2 in /usr. When the program
starts, it reinstalls the symlinks if necessary (can be done by
adding the 'ln' command in 'AppRun' script inside /root/my-roxapps).
Hence it doesn't matter if Puppy deletes them. Putting all files in
one place makes it easier to uninstall too.

More information on creating a DotPup can be found here.

If you've installed any DotPup, you'll probably see those 'icons'. They are not icons actually. They are folders, or what we call 'application directories' or 'wrappers'. To view their content, right-click on the 'icon' and choose 'Look Inside'.

'App Dir' and 'Wrappers'

Application directories (App Dir) are self contained applications. The directory contains the program's help files, images, binaries and possibly other things. They may still depend on other libraries, though. A typical App Dir would be '/usr/local/apps/ROX-Filer'. An App Dir does not normally need an installer - you can just move it wherever you want. You can `uninstall' an application by deleting the directory. You can run an App Dir by clicking on it. However, what most DotPup makers put in /root/my-roxapps are 'Wrappers' only'.

Wrappers are tiny application directories which just run an already-installed version of the program. For example, a program will have images, binaries, resource files, etc, installed in /root/my-applications/XXX and has a wrapper in /root/my-roxapps. Inside the wrapper there are basically four files / folders:

AppRun - an executable (you can open it with a text editor to view the code inside). It'll execute the binary in /root/my-applications/XXX. It can also include codes that do things like uninstalling the application.
.DirIcon (optional) - a PNG format icon
Help (optional) - a subdirectory with all the help files inside
AppInfo.xml (optional) - used to customize the right-click menu, show a tooltip for the application, etc

So, to make a wrapper for your DotPup simply clone and then edit the above four item of any existing wrapper you have in /root/my-roxapps (e.g, XMMS), and then rename the folder to the name of your software. more Info

Since Puppy 1.0.5 we have a new script called PCCC (with GUI) to create your custom puppy live-CD. This program enables you to use the current live-CD as the starting point, then add or remove packages as you wish. PCCC is tied in with the PupGet package manager, and can also move DotPup to the live-CD. Barry: "I have setup PCCC so that it defaults to choosing all PupGets and registered DotPups to be moved to CD, except for those installed to /root/my-*-- those by default are not chosen, but can be chosen manually. So, anything that installs any files into /root/my-applications or /root/my-roxapps would not be chosen by default. And of course any unregistered DotPups get ignored by PCCC so will not be moved to CD, regardless of where they are installed." (quoted from this post). See this page for more information and other methods to remaster a Puppy CD.

So two things to consider:
1. Do you want your DotPup to stay when Puppy is upgraded?
If so, put it somewhere in /root (no need to register with PupGet). Or put it somewhere in /usr AND register it with PupGet (as files in /usr that are not registered will be overwritten when Puppy is upgraded to a new version)
2. Do you want PCCC to include your DotPup?
If so, you MUST register it with PupGet no matter where you put it. If put in /usr, it's chosen by PCCC by default. If put in /root, it can still be chosen manually by the user when running PCCC. The latter is not prefered if your DotPup is not small in size, since files in /root are added to image.gz by PCCC, while files in /usr are added to usr_cram.fs. 'Image.gz' is a basic file system that loads into a "ramdisk" (a filesystem that's totally in RAM) when Puppy boots and should be kept small (otherwise Puppy will be slow). In short, if you have files registered with pupget, it would be better to put them in /usr than in /root. To learn how to register files with PupGet see this page.

Put in /root usually means /root/my-applications or /root/my-roxapps
Put in /usr usually means /usr/local or /usr/local/apps
Also, if put in /usr, Puppy has a few peculiarities you have to be aware of. You may want to avoid putting files in certain directories too. Again, test your DotPup thoroughly before you upload it (especially if you decide to put it in /usr).

For a discussion on where to put your DotPup, read these two threads: 1, 2.
Make sure you read the WHOLE thread, there are diverse opinions there, including advice from the creator of the DotPup system GuestToo. Personally I prefer putting my DotPups in /root, because of the special way Puppy works (see Basic Concepts):

The folder /root/.usr is mounted everytime Puppy boots, thus making the directory /usr writable. Strange things may happen if your DotPup is installed there (especially when we have Multi-session Puppy which can save each session back to the CD/DVD). Also, since new versions of Puppy are released every one or two months, the content of /usr (usr_cram.fs, where most programs that comes with Puppy are installed) change very frequently. Putting your DotPup in /root (e.g, my-roxapps or my-applications) would increase the likelyhood that the DotPup (which is created in a older version of Puppy) would still work in newer versions of Puppy. And most importantly, it's less likely for a DotPup in /root to mess up other's machines, even if a version of Puppy different from yours are used. What's more, if the content of /usr (i.e, /root/.usr) or /etc (i.e, /root/.etc) are changed wrongly (by a DotPup), Puppy may not boot. So it's my practice to avoid that two folders. It is very important that a program does not make any harm to other's system, even MORE important than the functioning of the program itself. But that's just me, there are different reasons for people to put DotPups in /usr. One great thing about Puppy is the flexibility and diversity it offers. Read the information provided and choose your own way.

-puppian-

JonathanMarsden: For very small packages, generating a list of the files to include in your dotpup.tar.gz archive by hand (editing the make-tar script, using some documented approaches) is feasible. However, this does not scale at all well. When a package has tens or hundreds of files, generating the list of files to be included in the dotpup.tar.gz archive needs to be automated. Here is one way to do that, for packages that you generate using the common automake ./configure && make && make install type of process.

• Download the source tarball
• Untar it
• Configure and build the package
• Create a timestamp file
• Install the package
• Create a tarball of all files created after your timestamp file

Here is an example:

# wget http://easynews.dl.sourceforge.net/sourceforge/joe-editor/joe-3.3.tar.gz
# tar zxf joe-3.3.tar.gz
# cd joe-3.3
# ./configure --prefix=/usr/local
# make
# touch /tmp/timestamp
# make install
# tar zcf dotpup.tar.gz `find /etc /usr/local ! -type d -cnewer /tmp/timestamp`

Many packages generated in this way default to installing into /usr/local. If your package does not do this, try using configure like this ./configure --prefix=/usr/local.

Of course, you should check that the contents of your new dotpup.tar.gz are what you expect, but this approach can be a huge timesaver in packaging applications as DotPup archives.