Building better dotpups

How to do things, solutions, recipes, tutorials
Post Reply
Message
Author
User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

Building better dotpups

#1 Post by Nathan F »

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.

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
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
Last edited by Nathan F on Sat 16 Jul 2005, 14:04, edited 1 time in total.

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#2 Post by Flash »

Thank you for that :!: A thoroughly educational post. :) I'm putting it in the index.

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#3 Post by GuestToo »

the main idea was to make dotpups easy and similar to "clicking on installxxx.exe where xxx is the name of the program" ... i would also be using the browser as the gui
kiss
why reinvent the wheel

i also wanted dotpups to be easy to create

i wanted them to automatically unzip themselves and run themselves (so it isn't necessary to explain tar and gz and md5sums etc etc)

i included a thorough md5sum check, because sometimes files don't download properly

dotpups are zip files rather than tgz's because servers often have the mime settings wrong for gz files ... which can corrupt a download, and cause a browser to display the link as text rather than downloading it ... nothing to stop you from putting a tgz inside a dotpup though

executing dotpup.sh automatically instead of running a default installer program means a dotpup is very flexible ... it does what the creator programmed dotpup.sh to do

roxapps can be made so they can be moved to another dir or drive (some won't work right on a vfat drive) ... there are advantages if they are in a fixed location like my-roxapps (eg. the menu can find them ... they can be symlinked of course)

Barry setup a method of registering alien packages (eg, dotpups) ... i haven't used it much myself, because i usually worked around /usr by installing files somewhere else (usually in a roxapp or in my-applications) and making a symlink or 2 in /usr ... when the program starts, it reinstalls the symlinks if necessary, so it doesn't matter if Puppy deletes them ... putting all the files in one place makes it easier to uninstall too

rox appdirs can be run from a menu ... for example, if you have /root/my-roxapps/BashBurn, you can run it from the command line (or menu) with rox /root/my-roxapps/BashBurn or /root/my-roxapps/BashBurn/AppRun

you can use a rox dir like a menu ... click an application with the middle mouse button and it will run it and automatically close the rox window

fvwm95 and jwm have menu items in the same file as other configuration items ... if your dotpup changes the menu, if it accidently damages the configuration the wm may not start

when i make dotpups, is usually type something in rxvt to see that the line is correct and copy/paste it, or if it's a path to a file or dir, i usually hold the ctrl key and click the file or dir to copy the path to the clipboard so i can paste it into my dotpup.sh script ... this helps prevent some typos

i didn't include anything complicated in the dotpup handler, because i thought copying the method from another working dotpup (template) would be easy ... and helper programs could be written too

for example, instead of including instructions to register with PupGet in dotpup.sh (not that it's difficult), there could be a routine that could be called by a dotpup creator (already debugged) ... so a dotpup.sh could be something like:

tar -xzP --no-same-owner -f dotpup.tar.gz
register-dotpup "netcat.0.7.1" "filelist"
rox /root/my-applications/netcat/cryptcat.txt

it might be possible to write a routine to add menu items too

when you install a newer version of Puppy, do menu items that were added to the fvwm95 and jwm menus disappear? or does PuptGet reinstall menu items added by alien packages?

i have not changed anything in my original dotpup handler ... not that it couldn't be improved (in fact, i uploaded it thinking that while it was a bit rough, an updated improved version could be installed anytime using a dotpup installer)

the only improved dotpup handlers i uploaded were Lobster's dotpup handlers ... i was wondering if it would be better if the default Puppy dotpup handler was Lobster's dotpup ... it does not ask if you want to unzip it or install it ... that's the dotpup handler i usually use ... or the handler could ask each time, but it could have a "do not ask again" option

anyway, some helper routines to help dotpup creators do common things like registering with PupGet or adding/deleting menu items might be useful ... (i didn't think of dotpups as being a package management system so much as an equivalent to an installxxx.exe file ... so the routines would be a simple way to interface with the actual package management system)

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#4 Post by Nathan F »

There's a lot of information there. One of the main points I was trying to get accross is that dotpups can really benefit from registering with pupget. My reasons are plain above. I agree too that they should be easy to make. I don't really want to reinvent the wheel, just find ways to make it easier and more productive for the end user. Roxapps are an exception to just about everything that I said above, but they can be made even more user friendly if they can be called from the command line with a single word rather than a directory path. A menu entry is just a nice touch. What you mentioned about having the program reinstall neccessary symlinks is a neat idea that I'm going to have to look at doing with an AppRun script. My first one was little more than "start the program".

I don't expect everyone to adopt my way of thinking, and for a very small and uncomplicated application you don't usually have to think too hard to get it to work. I went to all of this work because there were some very heavy apps that I felt I couldn't live without for much longer. I felt that if I was going to this much effort in the first place I should make it the best that I can.
the main idea was to make dotpups easy and similar to "clicking on installxxx.exe where xxx is the name of the program"
Dotpups accomplish this remarkably well.

Also mentioned was having another routine setup to register or add menu entries. I like that idea. That takes the load off of the person writing the dotpup. It could work with the dotpup script as is right now and just be a seperate script that can be called from the dotpup.sh script to register the files.

Menu entries are another story altogether. The more WM's people get to work, the more menu's would have to be tweaked. I was actually looking into some control center gui tools for icewm earlier. They look neat but the problem is that most of them require python for some reason. I think people will be editing config files by hand for a while yet.

Thanks again for your words of wisdom.

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

KISS

#5 Post by Lobster »

Dotpups and pupgets have been a great success.

They make Puppy a lot of fun
(certainly the ideal is small pups) but larger files should also be available - clearly people are very pleased to have them - I know I am.

When I tried my first dotpup I could see they were easy to create but then managed to confuse myself. I will have another go in the future.

:oops:

The reason for the Lobster simplified dotpups which you were kind enough to implement, is because "Aunt Maude" (generic user) does not know or care about md5sum checking and does not need stray icons (so they are best deleted).

I use the dotpup default (not the Lobster ones) because it is the default and I reinstall so often that I forget to install the specialised Lobster dotpup each time.
:oops:

The info that is useful to Aunt Maude is in pupget - it tells you the progress of the downloading file.

At the moment we have two installers (Aunt Maude does not understand "package managers" who are people that work at the post office)

So the ideal is to combine dotpup and pupget (which is Barrys plan as I understand it) and to have one menu item which says "install more software"

There is no need in the future to mention dotpup or pupget (though at the moment there may be)

I was very impressed with the range of software that DSL is offering with its installer

It is also important that people are aware that Firefox, Opera, Thunderbird and Open Office (increase your utilities /resize root filesystem) all have built in installers that work with Puppy (and most distros)
It is likely this trend for top packages to be self installing will continue

KISS

yes indeed

:)
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

Bruce B

Re: KISS

#6 Post by Bruce B »

Lobster wrote:
[much redacted]

It is also important that people are aware that Firefox, Opera, Thunderbird and Open Office (increase your utilities /resize root filesystem) all have built in installers that work with Puppy (and most distros)
It is likely this trend for top packages to be self installing will continue

KISS

yes indeed

:)
  • I thought it might be worthwhile to add this: I think it is good that users are aware that one does not necessarily need to install major apps such as mentioned above inside the pupfile, the reason why is that they can be installed on any Linux filesystem and still be used by Puppy. (I suspect they could be installed on FAT32, but I've not done it)

    For a specific example: my Puppy file resides on a Linux ext3 file system located at hda6. On the very same file system is Suse. On this same file system is a directory called /shared.

    I install these major apps in /shared and run them from there. My pupfile is the default 256 MB and I have over half of it free. And I have lots of extra software installed inside it.

    I'd like to mention that Suse uses the same Firefox, Thunderbird, Audacity, and OpenOffice as Puppy uses. Even better, they use the same configuration files for Thunderbird and Firefox.

    (I developed a bad habit from Puppy, I always run as root).

    I recently installed Vector Linux on another filesystem and it will use the same OpenOffice, Firefox and Thunderbird.

    I particularly like sharing the configuration files for Firefox and Thunderbird because no matter what OS I'm running, the bookmarks for Firefox are the same, also the email for Thunderbird is the same.

    The OO works with seperate configuration files for each OS, but you can have a common user documents directory. For example: /shared/documents.

Bruce B

#7 Post by Bruce B »

There's a lot of information there. One of the main points I was trying to get accross is that dotpups can really benefit from registering with pupget. My reasons are plain above. I agree too that they should be easy to make. I don't really want to reinvent the wheel, just find ways to make it easier and more productive for the end user. Roxapps are an exception to just about everything that I said above, but they can be made even more user friendly if they can be called from the command line with a single word rather than a directory path.
And, Thank You.

Last night I made a RoxApp text editor called 'supernotepad'. It can be run as a RoxApp or from the command line. However, there would be no reason I imagine to register it. It won't get altered on a Puppy version update.

I guess the considerations would be involved around how the package would be affected by a version update.

If one considers menu items a very important factor, then it might be best to simply reinstall the dotpup after the upgrade. Or have a repair routine to fix the menu items. Except that it is so simple and fast to install most dotpups, I don't know if a menu upgrade routine would be any easier for the user to locate and run than it would be to run the orginal dotpup?

Of course the menu items could be checked by some automated system put in place.

Personally, and this is personal, I usually do a fresh install. This is for a few reasons, two of which are listed below:
  • * I like clean installs over upgrades

    * Since I install just about every package available, I've learned which ones I want to reinstall and which ones I don't. For this reason, a Puppy new version release is an opportunity to clean house.
But those are just my preferences and we don't make dotpups for ourselves, we do it for the community.

That was some very good work you did and when I need it I'll use the template. I appreciate your contributions. Thanks again.

Bruce B

#8 Post by Bruce B »

A statement from G2...
... i also wanted dotpups to be easy to create
Lobster, I've been anxiously awaiting your first dotpup. If you are up to the challenge, I'd like to give you an easier dotpup to make for your first.

There is a little command line utility called tree which does all kinds of cool stuff.
  • usage: tree [-adfgilnpqstuxACDFNS] [-H baseHREF] [-L level [-R]] [-P pattern]
    [-I pattern] [-o filename] [--version] [--help] [--inodes] [--device]
    [--noreport] [--nolinks] [--dirsfirst] [<directory list>]
    • -a All files are listed.
      -d List directories only.
      -l Follow symbolic links like directories.
      -f Print the full path prefix for each file.
      -i Don't print indentation lines.
      -q Print non-printable characters as '?'.
      -N Print non-printable characters as is.
      -p Print the protections for each file.
      -u Displays file owner or UID number.
      -g Displays file group owner or GID number.
      -s Print the size in bytes of each file.
      -D Print the date of last modification.
      -F Appends '/', '=', '*', or '|' as per ls -F.
      -t Sort files by last modification time.
      -x Stay on current filesystem only.
      -L level Descend only level directories deep.
      -A Print ANSI lines graphic indentation lines.
      -S Print with ASCII graphics identation lines.
      -n Turn colorization off always (-C overrides).
      -C Turn colorization on always.
      -P pattern List only those files that match the pattern given.
      -I pattern Do not list files that match the given pattern.
      -H baseHREF Prints out HTML format with baseHREF as top directory.
      -R Rerun tree when max dir level reached.
      -o file Output to file instead of stdout.
      --inodes Print inode number of each file.
      --device Print device ID number to which each file belongs.
      --noreport Turn off file/directory count at end of tree listing.
      --nolinks Turn off hyperlinks in HTML out
I've attached it to this post, I hope you are up to making a dotpup out of it.

You encouraged me to make my first dotpup. I'd like to return the favor and give you some encouragement.
Attachments
tree.zip
(13.34 KiB) Downloaded 1254 times

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#9 Post by BarryK »

A good read, guys.
Nathan, GuestToo, it was helpful to read your summarys/assessments.
Lobster thinks I have a plan.... :lol:

Yeah, DotPups that don't go into /usr don't have to register with Pupget, except for the advantages mentioned by Nathan.
Some kind of new way of handling the menus is needed ...there were some ideas floated awhile back.

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

Re: KISS

#10 Post by Lobster »

I install these major apps in /shared and run them from there. My pupfile is the default 256 MB and I have over half of it free. And I have lots of extra software installed inside it.
:)
m m m . . .
I rather like the sound of that . . .
Puppy has always been promoted as the Pup to the big dogs of Linux . . .
but increasingly many of us (and I am one of those users) prefer using Puppy to any other distro - even when we have the choice of big dogs.

I have Ubuntu on my HD (it allows me to download pics from my camera - just worked - wonderful) I can not do that with Puppy or have not worked out how to . . .
Maybe Mut will develop to allow this.

I will try and remember this shared directory installation
I feel it is quite an important concept. Perhaps someone will understand and explain why . . . (I do not fully understand where we go with this idea . . .)
I'd like to mention that Suse uses the same Firefox, Thunderbird, Audacity, and OpenOffice as Puppy uses. Even better, they use the same configuration files for Thunderbird and Firefox.
I know a lot of people use different OS on different partitions.
I use one per hard disk (for reliability)

but if we can somehow stardadise or computerise this into dotpup or pupget
- or would it complicate things - maybe we need the Bruce Dotpup?

. . . quite intriguing . . .


(I developed a bad habit from Puppy, I always run as root).
youse is a bad pup!
eh . . . does it matter on a single user machine?
does not seem to . . .
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#11 Post by Nathan F »

I want to second Lobster's remark the the shared directory idea is a good one. I especially love the idea that email could be shared between different OS's. When I first started using Puppy that would have been an incredible bit of info as I was running Mepis, too. Bruce, if it hasn't already been done could you write up a how-to on that? Or maybe Flash can link to this thread for the info.

Interestingly enough I've since become one of those people who doesn't use anything else othe than Puppy. It works and seems to work better with each release. My thoughts are that there are concepts in how it is put together that can be universally applied to making any Operating system better, many things which have been applied in a completely new and uniqe way. Like I said up above when I saw Gimp open almost instantly I was completely shocked. I kept opening and closing it over and over again just to make sure I wasn't seeing things. People will soon be able to witness this behavior with OpenOffice also. I think Puppy is going to be taken much more seriously in the future.

By the way I updated the code slightly up above after I found my little mistake. The concept seems solid to me and works well. My next project will also check to see if there is an entry in alienpackages.txt before it tries to write one there. That would make it easier to use the dotpup to just repair an install if some files got damaged or erased.

Nathan
Also anxiosly awaiting the first lobster.pup

Bruce B

#12 Post by Bruce B »

Sure Nathan, I'll post the details here in about 5 or 6 hours, but I'm out the door right now.

Done! It seemed like a new topic, so I posted the write up here: HOWTO Install certain major applications outside pup001

doopdoop
Posts: 48
Joined: Thu 28 Jul 2005, 08:38
Location: Magdeburg, Germany

#13 Post by doopdoop »

Just a small help for package builders

If you want to build packages, but do not want to install in your real filesystem:

tmake a temporary folder, in which the files should go:

Code: Select all

mkdir /tmp/fancypkg
run ./configure and make the usal way with your default options
but run

Code: Select all

DESTDIR=/tmp/fancypkg make install
This should work with most packages which use autoconf (most Linux applications do).
This will copy the program files to /tmp/fancypkg/usr/ and /tmp/fancypkg/etc and so on, so that you can modify and package there without to touch your working environment.
Remember, that the compiled program still expects to find the necessary files in /usr and /etc. This is just for creating packages.

Post Reply