I only recently became aware of the deb2tgz program and haven't looked at it at all. src2pkg does convert *.deb packages to slack-format packages in the same way that it does with rpm binary packages. If you point src2pkg at an rpm, it figures out if it is a source archive or binary package. If it is a binary package it will simply convert it to a tgz, but the resulting package content is subjected to the same treatment as other binary package content -it tries to make sure that directory permissions and layout are correct, etc. If the rpm is a source archive, it will try to compile it -it doesn't convert the rpm source archive into a tar.gz source archive.

src2pkg does not try to do anything with any installation scripts which are included in an rpm or deb binary package. If 'alien' does so, it may do a better job of conversion than src2pkg. I haven't checked the internals of alien closely, so I don't really know how well it works or exactly what it does with 'prerm', 'postrm' or other included scripts.

As T3slider said, converting binary packages from another format is a really lame way to get a program for your system. I added the functionality to src2pkg because I see that most people use rpm2tgz to convert binary packages instead of source archives and I was sure that src2pkg would do a better job than rpm2tgz -it already included all the code which could correct possible errors and just needed to be taught to recognize and accept binary rpm's and do the proper thing with them.

If you are converting packages as a regular practice, you might be better off to use the alien program as that is its' main purpose. The main purpose of src2pkg remains that of working with source archives. In my repository, I use many rpm source archives and 'debianized' tar archives because they usually contain valuable information, documents and extra files, such as patches, which are not part of the regular sources.

Thanks T3slider and gnashley,

one more question, does src2pkg prepare the package file under /var/log/packages for binary packages (rpm & deb)?

thx

Yes, of course, but for binary packages it will only prepare a generic slack-desc file. You can run 'src2pkg -N archive-name' first so that a generic file will be created, then you can manually edit it to add whatever text is wanted there.
One of the fairly recent new features of src2pkg will read a debian/control file and use the Description text to prepare a slack-desc file. This only works for debianized sources though -not when converting debian binary packages. Maybe I'll have a look at getting it to do that though, now that the subject comes up -since debian binaries always include this file -binary rpm's do not always contain a file which can be parsed for this info. src2pkg will check and correct the directory permissions and paths for you, though -binary debian and rpm packages usually place the docs and man-pages wrongly for the Slackware dir layout.

Hi All,

Thanks to this nice post, I've been shown the ways of src2pkg.
I like its concept ALOT better than configure/make/make install
GREAT, except ONE PROBLEM.

I was trying to install dump.0.4b41-i486-1 from the source I downloaded.
<This package has the dump/restore commands I use to snapshot/poor man's mirror my os partitions to another drive/partition, BTW>

So I run the src2pkg <sourcecode.tar.bz2>
and it makes the package, but gives an ambiguous error on the make, but also says the error might be ignored.. no real information about what the problem was... See output
.
.
.
<happy compile messages>
Checking for 'install' rule - Okay
Checking for DESTDIR, INSTALL_ROOT, PREFIX or CMAKE_INSTALL_PREFIX - Okay
Installing using prefix - Using:
make prefix=/tmp/dump-0.4b41-pkg-1/usr install
Notice - Possible error running 'make install'
NOTICE - Must have been a false error as files were found.
We'll try ignoring it. Reoprt this to me if it doesn't work.
Correcting package permissions - Done
Stripping ELF binaries - Done
Checking for standard documents - Done
Creating slack-desc - Creating slack-desc file in PKG_DIR
Searching for links in PKG_DIR - None found
Making installable package - Done
Package Creation - Successful! - Package Location:
/tmp/dump-0.4b41-i486-1.tgz


So I install the package and it happily installs, but I find it is incomplete. It lays down "dump" but is missing the "restore" command.

So since this does not work, I go back to the old way of configure,make, make install.
On the make install step, I see the error.
It complains that I don't have a user account "man".
So I quickly add "man" to /etc/passwd and shadow.
THEN, I try the src2pkg again.. This time it works great, no errors and is complete.


So!! My question is..
How could I have avoided doing the manual make;make install steps to view the compile errors and gotten src2pkg to give me that information instead???
By having to do the make/make install steps manually, I half installed the software to my system, and was uncertain what actually got installed, which is EXACTLY WHAT I WAS TRYING TO AVOID by using src2pkg in the first place.

FURTHERMORE, I am now concerned about future partial src2pkg installs, I was lucky I noticed the "restore" command was missing, because src2pkg did not abort when it encountered this error, it made an incomplete package. Luckily this package was only a few commands, otherwise I might not have caught the error.

P.s. Slackware 12.1 feels much better than 12.0. And 12.0 was rock solid, i only upgraded for the fun of it, but sure glad i did. Its the little things...

Thanks in advance,
-Mike

If you use QUIET=NO enviroment variable or pass in -VV as an argument (same thing internally), you'll get all the output from the build steps.

As advanced as src2pkg is, like all programs it still can't handle everything and some of the assumptions made in coding it might not be valid, but it does inform you whenever it encounters such limitations. In this case src2pkg told you that something weird happened and that you need to manually check the package for correctness. In fact, for any package you should generally do a quick file listing with 'find' in the package directory and check that there aren't any major glaring problems. src2pkg doesn't seek to totally replace user involvement, but supplement the user with an "85%" solution so that the user can concentrate on the unusual 15%.

Thanks for the issue report, but in the future please start a new thread instead of hijacking an existing one.