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

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

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

Thanks, Gilbert, we've all calmed down now. My pulse has gone down from 192 to its normal 66... :)

That is a good question. I don't have an immediate answer. :) I think src2pkg is fast becoming a popular tool. Popular tools should accommodate all users, not just the propeller heads.

Frankly, I'm tired of the "no GUI" responses throughout the Slackware community. I think all such proponents should be required not to use X at all. Use links, use pine, use your god-ammed vi or emacs, stock up on Twinkies, buy some more tin foil, and ask mom if you can have your bedroom and shop back in the basement of her house. I'm tired of the "no GUI" elitism that appears every time the topic arises.

The world has changed. Just about all people in the developed regions of the world nowadays use computers. The majority of them have no more interest in mastering vi, emacs, or the command line than they do in changing the engine oil in their cars. All of these people could care less about the underlying operating system. The operating system is merely a foundation for their apps.

I use the command line all day long. I use GUI apps all day long. I use text editors and I use word processors. I use a simple calculator and I use spreadsheets. I use a telephone and I use email. I use Konqueror and I use midnight commander. I use scratch paper and I keep notes on my computer. I use whichever tool I'm in the mood for and whichever is productive for me at that moment.

What exactly drives that element of the Slackware community that everything about computers is supposed to be so god-ammed hard? Is this some kind of hidden Eleventh Commandment? If that element of the community controlled television and radio, people would have to write f-cking shells scripts just to change the channel and recompile kernels to rotate the antenna. People would be hung simply for mentioning the idea of a remote control. If some Slackers controlled the world they would demand everybody use square tires.

I suspect every person participating in this forum uses X and a GUI web browser to participate. What is the difference between a GUI web browser and a GUI admin tool? Not a f-cking thing. Yet somehow, every time somebody raises the topic of adding GUI admin tools, the "non GUI" gear heads start frothing at the mouth and accusing everybody of blasphemy. Please step aside. The rest of the world is moving on.

The GUI discussions in this forum never has been an either-or discussion. The discussion always has been about augmenting and extending good underlying command line tools. To extend usability for all users. To make free/libre software accessible and usable for all users and not just a privileged few and computer elite.

Personally, I think a CLI with a multitude of options is preferable to a complicated GUI with a dozen menu bar items and a dozen items in each menu. I'm about as far from being elitist as you can get, too.

Please calm down, Woodsman.
The reason that I prefer a non GUI approach in Slackware is that when you introduce GUIS that comes with a price, that is, more system overhead. I'm not an elitist, I am pragmatic. Slackware functions just fine without GUIs so if it ain't broke why fix it?