-   Slackware (
-   -   convert deb2tgz... is it possible...? (

Alexvader 01-12-2010 03:35 PM

convert deb2tgz... is it possible...?
Hi Forum

Same way there is an rpm2tgz, is there a deb2tgz...? ( guess asking for an exe2tgz would be too much heh...!? :D )

Or a slackBuild for Alien... ?

... No, I do not mean Eric, :D ROFL

I mean the application that converts between rpm tgz and deb... :)



affinity 01-12-2010 03:39 PM

Google is your friend :)

Alexvader 01-12-2010 03:46 PM

Thks affinity :)



gnashley 01-12-2010 04:17 PM

src2pkg *.deb

hoodooman 01-12-2010 04:17 PM

You could try Slackpack.It should convert from .deb and .rpm

knudfl 01-13-2010 12:31 AM

Under the hood a Debian package is ' data.tar.gz '
+ some small "install helper files".
All packed up in an 'ar' archive.

ar x <package>.deb : will unpack the files.
.. So the primitive method is just to rename
data.tar.gz to package-name.tgz .

( " 'dpkg -x <package>.deb' <folder> " will unpack to
"your choice of folder". )

Besides the converting commands mentioned in the above
posts, # alien -t <package>' will also create a ' .tgz '.

Alexvader 01-14-2010 09:30 AM

Hi @Gnashley, @Hoodooman, @Knudfl

Thks for your replies :)

@Knudfl : I had already figured the contents of a *.deb, but one thing still puzzles me... when Installing a *tgz in Slack, the performs the last operations in the install process, I do not know ( ...even if it is necessary ) how to translate the corresponding mechanism from gdebi <foo>.deb to installpkg <foo>.tgz...

Simply extracting, repacking and renaming would loose all the post install features of a *.deb IMHO...



knudfl 01-14-2010 11:28 AM

# 7

.. would loose all the post install features of a *.deb
Which post install functions / procedures are you missing ?

An example package, you have tried out,
may help enlighten your issue.

gnashley 01-14-2010 11:33 AM

You might extract it once manually and copy any postinst file to and then package it using src2pkg. The real advantage to using src2pkg is that you get all the package 'lint' functionality to make sure the dirs and perms are on par with Slackware. But, you mention it, so I'll look at adding code to the routine which handles debs and (maybe) have it automatically trun postinst into files -but it may not be a good idea, depending on what is in the file. If the debian package contains any links, they will be handled by src2pkg by removing them and creating a and adding the lines which create those links.

Woodsman 01-17-2010 02:57 AM


I don't pretend to understand your voodoo and magic with sr2pkg, but would you please describe the tool's ability to convert deb packages, any related known bugs and shortcomings, related future work, etc.?

A common complaint about Slackware is the lack of an official central repository and the overall lack of packages compared to the Debian platform. If your tool can convert deb packages and create Slackware packages then this would be good news and something others might want to know. Users would still be required to build packages rather than just downloading, but having access to 20,000+ packages could remove any perceived inconvenience.

Second, do you have any future plans to provide a GUI for src2pkg?

Thanks for your time and work.

gnashley 01-17-2010 03:37 AM

When src2pkg unpacks a 'source' it looks at it to figure out what it is. Usually the 'source' is really sources, but when you pass the name of a binary package as the source, it is able to tell(usually) that it is binary or packaged content because of the presence of directories like usr, etc, or other. When this is the case, then it simple filters this content into the package tree, ignoring the normal configure, make, make install routines.
But then, the content is subjected to all the normal content processing steps, so you can be sure that permisson and ownerships are correct, that man and info pages are in the right place, etc. And you also add any extra content to the package (if using a NAME.src2pkg script) or use any of the 'advanced' features.

Like most Slackers, I do not encourage people to convert pre-compiled packages. But there are cases where no alternative is available, so that's why I built this functionality into src2pkg. It does provide a much better way than simply using rpm2tgz or deb2tgz -because of all the sanity checks and corrections.

Now about the GUI, a few people have asked for this over the years, but I have never placed any priority on it -I don't see a GUI making it any easier really. If all the available options were given a place in the GUI, then the inetrface would be pretty complex. I have put considerable effort into keeping the command-line interface as uncomplicated as possible, while keeping flexibility. And the syntax/usage of src2pkg scripts also aims to be as simple as possible -even for non-script-gurus.

There is a way to use src2pkg with a drag-n-drop frontend which I use all the time as it saves me having to type the filenames. But I *always* use a script for my builds. If unaltered, they keep the '.auto' suffix so I can tell at a glance that they are 'generic'. If I make any changes, I remove the '.auto' suffix before editing them.

But tell me, what you think a GUI should present to the user? I am open to any ideas.

brianL 01-17-2010 06:20 AM

No, no GUI. It's great as it is.

gnashley 01-17-2010 10:54 AM

Any GUI would just be a front-end anyway -src2pkg already is setup to be controlled by external scripts which 'drive' it, so no extra code would be needed in src2pkg itself.

hitest 01-17-2010 11:02 AM


Originally Posted by brianL (Post 3829530)
No, no GUI. It's great as it is.

Agreed. I also like src2pkg just the way it is. No GUI please.

gnashley 01-17-2010 11:23 AM

I promise that there is not going to be some default GUI to src2pkg. If there ever is any sort of GUI, it will be completely separate from src2pkg and will not get in anyone's way who doesn't want it. Now calm down, fellows...

All times are GMT -5. The time now is 01:28 AM.