Linux has been a fun treat. I am a little baffled why this was so much work. Creating a .deb file was not as simple as I thought it was going to be. To get what I needed to get done, I actually downloaded several existing deb files, like putty, and unpacked them and examined the various files inside.
Once I got it, I created a script to generate a deb file for me, but it still needs work.
I’m a huge fan of static linking. There are several programmers who make the argument, it will bloat programs and it isn’t good practice. I say, Pfff!
Flirc as a static compile in linux, is 8.6 MBytes. What is it when it’s not a static compile? About 1 MByte. So what are the downsides? My server is going to send more data. It will take up more space on client computers. What is the upside? I don’t have to deal with dependency nightmare that is arguably the major flaw in Linux. Worth it…
I’m still having issues with libusb, so I I currently have two binaries. A 64 and a 32 bit. They have been posted on the Linux Downloads Page.
Check out the bottom, add the repo to your source.list file and get automatic updates. Please remember to send me feedback.
I suppose it depends what libraries you’re using and how often you’re going to need to push out a new binary whenever there’s been a significant change in those libraries.
If you don’t mind shifting that extra data then I suppose it’s all good.
As for dependency nightmares etc, APT is a very powerful package manager.
As long as there aren’t any huge changes either within your application or the libs you’re using upon update then it probably won’t be as hairy as you think it’ll be.
I can see why you’ve opted to go with static linking though.
Maybe throw together a dynamic compile and privately test it over the course of a few updates.
* Huge changes that break compatibility that is… Static version checking on your part or deprecation or name changes of library functions.
In which case you’d still need to address those problems if you were intending to use the updated libs.
Thanks for the comment. Yeah I understand and would have to agree about the kick but dependency resolution in Ubuntu and most distributions. But in this circumstance, I didn’t want the users to have to install the entire qt lib base, which ends up being a clutter and waste when I’m only using a few libraries.
You really go to discredit yourself with this line “I don’t have to deal with dependency nightmare that is arguably the major flaw in Linux.” In all my years of running Debian I’ve never come across ‘dependency hell’. APT is one of the most powerful packaging tools out there:
Have you seen how big the libqt install files are?
libqt4-core is 110kB
libqt4-gui is around the same size.
If you’re just trying to replicate the package format, please DO NOT release a .deb. Just release a tar.gz or something, that way other distributions other than Debian/Ubuntu can use it. If you are going to make a deb, please don’t hack it together. There are plenty of How Tos out there on how to build a deb correctly:
And if ttf-mscorefonts-installer is a requirement, then add it to the list of requirements, apt will handle that.
@James – Thanks for the comment, I really appreciate it. Yes you are right, the distribution handles the dependencies. I’ve given up. I tried compiling QT myself and am having huge performance issues regardless if I compile static or dynamic.
I ended up compiling with the stock ubuntu. I do an LDD on the binary. I check all the dynamic libs and find which package they are located in with apt-file. I add those to the list of dependencies in my control file.
I downloaded plenty of deb files and unpacked them to see how they work. The result felt like a hack, I’ve read through both those that you pointed out while previously trying to put it together my deb file. I’m just a person who relies on examples to learn.
Again, thank you for the comment. The new i386 binary is live and the rest should follow. Let me know if you have any trouble. That’s a really good tip about zipping all the files, I’ll do that as well.