I am having trouble turning the webmin source into a package. durring the src2pkg process, when i get to the install command part i run through the webmin config. i think this is where it all goes to hell. i follow through the setup like i normally would (just agree with all the default destinations). src2pkg completes and creates the package file just fine but when i install it, not everything is being installed. nothing in the /usr/local/webmin nor the /etc/webmin. all those files are get left in the src dir and never put into the pkg.

Here is the command i am running
maybe there is a better way to do this or someone has already got it to work?

I know the webmin build script at SlackBuilds.org creates a working package.
Note that this should not at all be construed as a stab at src2pkg - it just so happens that I personally tested the webmin build script and tried it out with a few things (including pptp-client) :-)

You know, i always forget about that site. Thanks!

I hope gnashley will reply to this, also. I have been using src2pkg more and more, and am interested in how it can handle unusual cases like this.

Brian

Ahh webmin. This a very good example of how much work it can be to get a good package which works correctly on Slackware.
I actually was able to get src2pkg to make a package of everything that gets installed with the setup.sh script. But that doesn't really give you a smoothly working setup. Kudos to Robby, who went to the trouble to work out the fine details and write the rc.webmin script as well as smooth out the setup.sh-based part of package creation.

While src2pkg could create the basic package natively, it takes it a very long time. webmin installs an incredible number of files .over 14,000 of them. And src2pkg double and triple-checks them all during package creation. In cases like this it is much better to insert manual code to streamline things. I downloaded Robby's SlackBuild and just cut and pasted the whole middle part into the middle of a src2pkg script and commented out about half the normal steps. This created the same package as the SlackBuild script would in a lot less time than the normal src2pkg way.

However, I went on to pay back the plagiarism favor, by making a couple of changes to the installation's default configuration which may make webmin a little easier and more flexible to use. In much the same way that Robby disabled some of the setup.sh options and then incorporated them into the SlackBuild, I hacked the setup.sh script down to create a configuration helper which installs to /usr/sbin. After installing the package you run webmin-setup to create the username, password and choose which port to run the service on. You can also re-run the webmin-setup tool at any time if you want to change the configuration.

You can get the src2pkg script and other materials from: http://distro.ibiblio.org/pub/linux/...s/webmin-1.350

Or, even easier -make sure you are connected to the internet, then cd into the directory where you have the source tarball and run:
src2pkg http://distro.ibiblio.org/pub/linux/...webmin.src2pkg

That will download the src2pkg script and execute it, which will download all the needed extra files. (If you didn't already have the source tarball it would download that too). After installation just run /usr/sbin/webmin-setup to setup the confiuration and start the server.

Well, I appreciate the kudos, but...
I didn't write the script - David Somero deserves that credit.
All I did was test it, make a few relatively minor changes and tweaks, and approve it for inclusion in our repository, so you might want to note David's name in there instead of mine.
Otherwise, thanks I'm going to refer him to your modifications too

You may find the webmin-setup useful for inclusion -possibly as a setup-type script. I just put it in /usr/sbin so it's in the normal path. I'll change/add the credits to David.

Wow, I can't believe you went as far as writing something like that up. Kindness like that can only be summarized as PURE AWESOME!
I've looked at all the scripts to see what i can learn from it. One thing i saw was the cmd install. Never knew that existed. The other package i was trying to make was Cacti, so I am going to take a swing at creating a script with what you've supplied for Webmin. Cacti doesn't require any ./configure or make process. just need to copy the files to the directory you wish to have them in IE your htdocs dir. Would you recommend using install or just use the mv cmd?

Another question i had about the Webmin script is why you decided to put it in the /usr/libexec/ dir? When I first looked into this i had looked at the slackbook for a description of the dir's to properly place the program. I figured /usr/share or /usr/local. i know that in the end it doesn't really matter, but what was your reasoning behind it and what is potentially wrong with what I though?

Also, if i wanted to use the latest and greatest webmin package would i just need to change the the following in the src2pkg script

Uh, you should realize that SOURCE_URL is kind of an addon. For use with sources which are already on your system you only need to supply SOURCE_NAME. src2pkg will look for the tarball in your SOURCES_DIR, which is CWD (the current directory) by deafult. You can change this to something else by editing your /etc/src2pkg/src2pkg.conf file. An example would be, say you want all your sources to be in one directory -like /usr/src/src2pkg/SOURCES. You could then put all tarballs in there and edit your src2pkg.conf file by placing this line in there:
SOURCES_DIR=/usr/src/src2pkg/SOURCES
Or using this:
! [[ $SOURCES_DIR ]] && SOURCES_DIR=/usr/src/src2pkg/SOURCES
will still let you override it on a case by case basis or from the command-line.

About SOURCE_URL, if the script includes that line, src2pkg will look for the named tarball in whatever directory you have set as the SOURCES_DIR *or* the CWD.
If you have the URL to a new version, but don't have the tarball available locally, yeah just edit the SOURCE_URL line. You'll want to re-edit the VERSION line also and the SOURCE_NAME. As I mentioned SOURCE_URL is kind of extra. In fact even the VERSION is not needed. If you supply only a SOURCE_NAME, src2pkg figures out all the rest -this is what happens when you run it from the command line
src2pkg name-of-tarball
When src2pkg creates a script for you, it writes out the NAME and VERSION for you, but they are not really needed. You can comment them out and it will still work. If the SOURCE_URL is the only thing given it still figures it out. The only problem is when src2pkg is unable to correctly guess the name and version (or you want to use something different than what it derives) -then you need to override its' guessing by passing ALT_NAME and ALT_VERSION. These will take precedence over the guessed values. The SOURCE_URL or SOURCE_NAME correspond to the actual name of the tarball. NAME and VERSION are what src2pkg guesses, and ALT_NAME and ALT_VERSION are your arbitrary overrides of the guesses. You can also easily manipulate the naming by creating a link to the tarball with the name and vesrion that you want or need.
You can do it like you have written there, but I really recommend that you always work in a separate directory for each package so that your generically-named files don't get clobbered. At least make it
/tmp/webmin
This keeps things much more orderly.

I used /usr/libexec/webmin because that was what was used in the unofficial SlackBuild -and because that really is the right place -for the same reason that src2pkg is also correctly installed under /usr/libexec. /usr/libexec is used for executable code which is architecture-independent. Since webmin is script based that's the best place for the files. If it used binaries for eveything then thy should go in the path. In the same way, src2pkg place its' FUNCTIONS and DEFINES files in libexec beacuse they contain code which is executed. generally libexec contains programs/code which is not called directly by the user but is called by other programs. You can also install such programs under /usr/lib/somedir or in someplace like /usr/somedir or /usr/local/somedir. Many programs do this, but probably less than before as these locations are rightly used for programs which contain real 'binary' programs which are architecture-dependent. To really be correct, they shouldn't install to /usr/somedir or /usr/lib/somedir, but instead to /opt/somedir. 'Anything goes' under /opt and programs aren't really supposed to create new directories under /usr. Anyway, you get the idea that filesystem hierarchy is complex and far from cut-and-dried.

As I mentioned, most of the guts for the webmin.src2pkg script were just copied from the SlackBuild -I usually just use copy and set the perms separately. Using the install command lets you set permissions at the same time and can be used for files or directories. PatV mostly uses 'cat' instead of install or cp. mv is basically the same as cp and then rm the original, but actually it is sometimes better than any of the above -especially for links. Your choice...

I've just downloaded cacti and had a look at it since I had never heard of it. The sources don't seem to conatin any real information about how/where to install it. I see that it is all php, so the best bet is to install it wherever you normally install php files. As with cgi files, this might be under /usr/www, maybe /var/www or even /www or /srv -depending on your setup. I'm not really versed on using these things so your guess is probably as good as mine. One thing I do see, cacti appears to expect fo find everything under the same directory. This is the case with most programs that install to /opt/?? or /usr/lib/?? (like mozilla,gcc). So to create a package with src2pkg. just comment out the configure, compile and fake_install lines.
then put
mkdir -p $PKG_DIR/wherever/you/think/it/should/go
cp $SRC_DIR/* $PKG_DIR/wherever/you/think/it/should/go

If there are programs in there which should be run like a command-line tool, then you'll need to either create links or wrapper which can be put in the users path.
I prefer to use wrappers as they are more flexible and it may be more obvious what they do. In that case, just create the bin dir in the package:
mkdir -p $PKG_DIR/usr/bin (or whichever bindir)
cp -mywrapper $PKG_DIR/usr/bin

If you create links, they usually should be relative. Say you want to put cacti in /usr/www and create a link to a program in the folder in the path:

mkdir -p $PKG_DIR/usr/bin
cd $PKG_DIR/usr/bin ; ln -sf ../www/someproggie someproggie

Hope this helps you without confusing you...