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...!? )

Or a slackBuild for Alien... ?

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

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

BRGDS

Alex

Google is your friend

Thks affinity

BRGDS

Alex

src2pkg *.deb

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

http://linux.softpedia.com/get/Syste...ck-34292.shtml

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 '.
.....

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 doinst.sh 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...

BRGDS

Alex

# 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.

You might extract it once manually and copy any postinst file to doinst.sh 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 doinst.sh 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 doinst.sh and adding the lines which create those links.

Gilbert,

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.

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.

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

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.

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

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

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...