Tag Archives: tarball

Dropbox in Debian Lenny (Gnome)

If you’ve been reading lately, you read where I installed Dropbox in my Slack64-13.0 and Slack64-13.1 on my desktop and laptop machines, respectively.

If you haven’t been reading, poo on you.

I use Debian on my desktop machine as a backup operating system. It’s fully functional and shares some common partitions with Slack; to keep synch’d somewhat. However, installing Dropbox would also be helpful for transferring stuff to and fro between these operating systems, which reminds me… I need to install Dropbox on my Win 7 laptop installation, too.

Anywho, installing in Debian isn’t quite as easy as it was in Slack, but it’s not that bad. Here’s how ya’ do it:

  • Download the source tarball from Dropbox’s site.
  • Untar it in your download or build directory.
  • Install the necessary dependencies using apt:

# apt-get install libnautilus-extension1-dev libnotify python-docutils

  • As root from within the recently extracted dropbox folder:

# ./configure -prefix=/usr/local

# make

# make install

# make clean

  • Logout
  • Login
  • Start Dropbox from the newly created menu launcher.
  • Follow the setup baloney.

Have FUN!



Let’s Play With Tarballs

A tarball is a compressed archive. Usually, a developer will provide his program in this format on his website or one of the third party software sites like SourceForge.

While it’s not normally recommended that you install software this way on your Linux system, sometimes it is necessary. The usual way to install software, of course, would be to utilize your particular distribution’s package management application (e.g., apt-get in Debian or Slackpkg in Slackware). There are inherent risks in installing software from tarballs onto your Linux system, especially if you’re unfamiliar with the developer or his reputation in the Linux community. Beware.

Let’s say you want to install Bill’s Clown Clock, but it’s not available in your distribution’s repositories. You do a search for it on Google and find that Developer Bill has provided a copy on LinuxApps4U’s website, so you surf on over there to check it out. It’s available for download, but… UH-OH! It’s one of those tarball things. How do you handle that? First, you download it to your computer, of course. Now that you have it on your system, you’re going to have to decompress that compressed archive… sorta’ like “unzipping” something using WinZip in MS Windows. Remember that?

Turns out your package that you downloaded is called billscc_v1.4.tar.gz. This is an archive that was created using the gzip archiving application. Great! Now, here’s what you’ll need to do to get that baby installed:

In the command line (c’mon… you didn’t think I was going to do the GUI thing, did ya’?)…

1) You’ll need to unpack the archive:

$ tar -xzvf billscc_v1.4.tar.gz

2) Navigate to within the new decompressed directory:

$ cd billscc_v1.4

Most developers will include a configure script in the package.

3) You’ll need to run that script:

$ ./configure

4) Now you’ll need make, make install, and make clean:

$ make (actually generates executables and other non-source files – GNU Make)

as root # make install (intalls the app globally for all users on the system)

# make clean (cleans refuse left from the compiling of the app)

If all went well, you just installed your first application from a tarball. COOL, huh? Like I said, it is sometimes necessary, but not recommended to install applications this way on your Linux system. You risk corrupting your system with poorly written configuration scripts, or worse, intentionally written scripts that trash your system. You never know. There are asshats in the Linux world, too. There’s also the possibility of sliding down the slippery slope into Dependency HELL! I’ve been there. You don’t want to go there. Believe me!

I used some information from berkshirelug.org in the creation of this article. I urge you to click HERE to view their excellent tutorial on installing tarballs.

As always, have FUN while you learn…


Note: Article amended to utilize the user/root commands in a more secure way. Thanks to Eddie Ringle for the suggestion.