http://iacs5.ucsd.edu/~pbang/uupt.htm

Since this is the Slackware forum, I don't think I have to say anything about why you would possibly want to use Slackware's dependency-free package management system on other distros. =)

That's basically what I've done with 'uupt' (universal/user pkgtools) -- taken Slackware's pkgtools (they're just bash scripts, after all!) and added a wrapper that sets the ROOT variable, among other things, to let one easily manage Slack-style tgz packages on any *NIX that runs bash.

I don't think anyone's packaged 'pkgtools' up for use in other distros. Why not? They're simple scripts and I don't see why the Slack philosophy can't (at least partly) co-exist with other distros.

With 'uupt', you can bring along a copy of Slackware's pkgtool scripts with any distro you happen to be using, and be able to make, install, and remove Slack-style packages either from system ('/usr') or user ('/home') locations.

What I fell in love with Slackware is how easy it is to make packages from compiled-from-source programs, and I'm hoping to bring some of that utility to other distros with uupt.

If you're already running Slackware, 'uupt' may not make as much sense, since you've already got pkgtools and you can achieve exactly the same thing just by setting ROOT.

But if you use another distro and would love to be able to manage packages just like you do in Slackware, please give this a shot.

It should act exactly like Slackware's pkgtools (because it *is* just that!) but on other platforms. I'm especially interested in how it handles in non-GNU environments (I've run into issues while testing it a bit on Solaris and OSX, but even then it's still mostly functional and useful.)

You'll find my src2pkg tool quite hansy for making packages and it has some built-in compatibility for other similar systems.

I searched through the forums and found it. Hey, that looks pretty cool. When I saw it was already a Slackware package, I just had to try it out and install it to my home directory using uupt. =)

I've yet to try compiling a source tarball with it, but just by running the sbin scripts without any parameters to get the usage text, I saw a problem with uupt: the paths are hardcoded into "/" in the scripts.

Not that I blame you; this was meant as a Slackware "system" package, after all. But adding a little change in your scripts would really make it more "non-root user"-friendly: configuring your paths to read from ROOT or PREFIX or some such and prepending that to your paths. For example, I saw that the libexec/src2pkg/installwatch script is set to read from PREFIX and base all paths relative to that-- so if you can just do the same for the other scripts (and also not hardcode PREFIX, heh), that'd be great.

A little more flexibility like that are what I wish more and more software authors would do to make their software more portable, in another sense.

In the current 1.0 version, the file /usr/libexec/src2pkg/installwatch is only used by the tracklist utility. For usage with src2pkg or trackinstall, the installwatch code is all within the functions.
You are mistaken about the hard-coded paths. You can change the default prefix or set the variable to whaever you like, either within a script or on the fly, by using the options with src2pkg. You can even set many variables from the command line which will override or add to what's in the script.
Trying src2pkg is easy. To start just place your favorite tarball in a new directory -try something that you know compiles okay first so see how simple it can be. Then just cd or browse into the directory, open a terminal and type 'src2pkg tarball.name' The man-pages are up-to-date, or type 'src2pkg -h' or 'trackinstall -h' to see the options. The main functions (formerly PkgBuild) have many more options available than the src2pkg and trackinstall scripts. They can be used within scripts or passed on the command-line.
If you make your test package using the -A option, src2pkg will write a build script for you. If you want to use some obscure option of PkgBuild (like SAVE_SPACE=3) you simply add that near the top of the script or run the script like this:
'SAVE_SPACE=3 bash mayprog.src2pkg'
The cross-compatibilty I mentioned means that you can use src2pkg with distros like DIY Slackware which don't have a slack-desc file. src2pkg leaves this filename as a variable as well as the name of the package installer. src2pkg can install packages as it builds them so there is a place where installpkg gets called. See lines 83-84 of /usr/libexec/src2pkg/DEFINES to change that so that srcpkg uses your proram to install the package.
At the current time, src2pkg only builds slackware-style packages that include the /install directory. Of course, this is one of the things you have dealt with in your code. However, I have been working on ideas and accessory programs which would allow you to make universal packages (like uupt) or make self-extracting packages which include an installer program -even a GUI installer if you want. The really nice thing about this is that you can unpack a package in a separate directory and perform operations before installing the files -like backing up files which will be overwritten, etc.
If you feel like cooperating, I do merge contributors patches, when useful. My program has benefitted greatly from 'conceptual input' from others. So, your comments and questions are quite useful to me. Feel free to snarf any code that looks interesting -I'm going to look at uupt and see if there's a line or two there for me, though I've been 'on vacation' from src2pkg for about a month.

From your README: what pkgtool has in mind by supporting the ROOT variable...
That is what makes it possible for you to run installpkg, etc from the installer and have the package installed on a partition which is not the '/' partition. It's not really menat for manipulation of the install prefix. While many binaries can be installed and run from anywhere, many others cannot be arbitrarily moved -this is/was especially true for stuff which installed to /usr/X11R6. You can usually tell by checking whether the program installs any shared (prefix/share) files which are used by the running program. If so, these paths are usually hard-coded or set at compile-time and can't be changed later.

Oh, sorry, I think you misunderstood what I meant by "/" being hard-coded into your program.

I didn't mean that 'src2pkg' can't make packages that are installed elsewhere-- I meant that your scripts themselves have some paths that are hard-coded.

Here's an example at line 52 of sbin/trackinstall:
Now, there's no reason why that can't be changed to this, can't it?
In the process of this little change, you introduce a lot of versatility.

I haven't gotten around to trying 'src2pkg' yet, but when I do and I have some more things to say about it, I'll let you know. =D

And so how do you propose that trackinstall would find the FUNCTIONS, by reading a config file? Then the path for the config file would have to be hard-coded into trackinstall, or at least a distinct relative path.
The src2pkg functions were originally designed to be always be used with a build script, so the build script template includes the sourcing of the functions as its' most significant line since the functions *are* the program. You can of course set this up more flexibly or alter it for your own ideas.
src2pkg itself just sources these functions for its' own use. I have broken backward compatibility a couple of times because of name changes and relocation of files. Notice that when FUNCTIONS is sourced, it in turn sources the DEFINES file and your system configuration file, if it exists. Because of the need for several critical variables to not be null, src2pkg will use sane default values even if the config file is not present.
The only way to do what you suggest and have a program be completely portable on a system at any time would be to code all paths relatively, or have all the code in one single file, with no references to any other library or binary. The PATH variable saves us lots of work when we call helper programs. However, I deliberately keep some things out of the usual paths to avois overrwriting files which might be included in another package, to avoid the user running programs which are not meant to be called directly and also for organizational reasons.
src2pkg is extremely versatile and already uses dozens of user-configurable variables. I have in fact removed some of them over the last year in a effort to simplify usage- there's no need to have features that nobody will use or understand. This really came to the fore when I started to write the trackinstall and src2pkg front-ends. Each of them could include many more options, but in order to standardize the syntax and make usage truly easy I have kept the number as low as possible.
You've looked at trackinstall so you might try it first -use it just like you would checkinstall for making packages from compiled sources. But it will even package pre-compiled stuff that uses an interactive installation script.
Also, src2pkg does a nice job of converting binary rpm or deb packages to the slack directroy structure and file ownerships, etc.

lol, I had a similar thought. Where would you source the config files that defines PREFIX then? So you'll need a config file for a config file... and that does sound pretty ridiculous. =)

But think about it: if PREFIX is not defined, then PREFIX is just nothing, empty, and so the line will read like it originally did:

But if you're like me and you like installing in your home directory, then I can, for example, 'export PREFIX=/home/arcanex/installroot' and that line, when executed, would now read:

and the rest of the script, if they followed the same PREFIX adjustment, should work exactly the same.

What's wrong with relative paths anyway?

Looking at the FUNCTIONS file, I see that you even insist on making 'src2pkg' be run as root-- is this truly necessary? That just makes me more paranoid. =)

Does 'src2pkg' absolutely need 1) write permissions to my devices or 2) write permissions to my system files? If not, then it doesn't need absolute root access... at least, not enough to warrant a premature root user check at the beginning of your script, when there could possibly be a lot of functionality a normal user could get from the rest of your program.

There's nothing wrong with relative paths -if only every program used them. But most programs don't, because you can't count on other programs and libs having been installed where you want them to be. This is why we have PATH in the environment and ldconfig -to fins those things for us. Otherwise every single program would have to contain code that searches for every library and binary it needs.
As for running as root, you can't install system files unless you are root. Many programs install some files into system directories. I figure that if you are making packages it's easiest to do so as root. I've looked at using fakeroot or other methods, but they only complicate things more. Running and compiling with a virtual machine is probably the safest way of all, but I can't assume that the user is running that way. I think that most people who have come to the point of compiling software and making packages have learned enough to be able to run as root without borking their system. You can't install much if you don't have write permissions. I throw you out early as a matter of convenience. There are many operations which could be done as user, but trying to slip in and out of root gets very complicated and could cause more problems thasn it solves. Do you suppose that Pat V. builds glibc while running as user?

I've done work on another system which compiles and installs programs in a personal or system directory and uses relative paths or prefixes which can be inside your home:
http://distro.ibiblio.org/pub/linux/...uilder-0.3.tbz