I want to be able to distribute a program in Linux without distributing the source with it. The current solution is distributing a tar.gz with a precompiled binary. What is the easiest way to have this binary be placed in the Applications Menu? Is there a way to do this that is common across most linux distributions, but Ubuntu, Fedora, and OpenSUSE would be the priority.
You will want to create a .deb and a .rpm. The former covers Ubuntu (Debian variants), and the latter Red Hat variants. You can also supply a standalone executable for other users who can deal with things like menus themselves.
You will have to deal with Gnome and KDE menu management, and also different distributions lay out their menus differently. There is also the issue of netbook variants such as Moblin, that have a netbook interface that probably has its own "add application" mechanism. I don't know if it is possible for a single .deb to handle both Gnome and KDE menus systems (for Ubuntu and Kubuntu respectively) but I imagine the capability is there to reduce duplication of effort for Ubuntu.
All recent distributions should have xdg-utils installed, which provides scripts such as
xdg-desktop-icon
xdg-desktop-menu
which seem to be what you're looking for.
Haven't looked into it lately...but back in the day (which really wasn't all that long ago) when I was using Linux, RPM was the easiest way to distribute pre-combiled binaries (most distributations had, and still have, some kind of support for RPM packages).
Here's an old how-to on building an RPM package:
Linux Online - RPM How-To
You could look at BitRock intaller.
Try Autopackage or other solutions posted in another question.
Do tar.gz and then give community rights to redistribute modified packages. They will make RPMs, DEBs and any other packages for their beloved distributions... which will probably fit their distros much better than you could ever make.
There is really too many differences between distributions to make one-size-fits-all package, often subtle ones. For example some distributions has "Application" section, other "Applications"... and this made menu items disappear on some distros. Libraries can be different, default settings can be different, and so on...
RPMs and DEBs aren't so portable as it is believed. With one package there might be problems even with different versions of a single distribution, and there is nothing worse than fighting to install badly prepared package correctly.
JeeBee is correct that you would want to go with .deb or .rpm.
For Ubuntu/Debian (the .deb) I would add that you do not send it to people but you create a "repository" and have the users add that url to their /etc/apt/sources.list, then you get a easy way to update the software as well.
That way you solve the distribution and updated problem at the same time.
And here is a example of how this could look like:
http://www.avrfreaks.net/wiki/index.php/Documentation:AVR32_General/Installing_tools_on_Ubuntu_Linux#Ubuntu_8.04_-_Hardy_Heron
And how a repository could look like:
http://www.atmel.no/avr32/ubuntu/
But don't repeat Atmels mistake and only do i386 because there is a lot of other common architectures out there right now, like the amd64.
/Johan
For RPM, this three-part tutorial by IBM is the best beginner's guide to packaging I know:
http://www.ibm.com/developerworks/library/l-rpm1/
http://www.ibm.com/developerworks/library/l-rpm2/
http://www.ibm.com/developerworks/library/l-rpm3.html
Related
I am looking for a solution how to duplicate a Linux installation for multiple systems. The Linux installation is based on openSUSE 12.2. All systems use the absolute identical hardware.
The official solution would be to use AutoYaST (see http://doc.opensuse.org/projects/autoyast/). But since all systems use the same hardware I was thinking about taking an disk-image from an installation and "dd" to all new systems? What do you think, any best practices?
try using the parted or gparted applications. gparted is the GUI for parted.
http://www.gnu.org/software/parted/manual/html_chapter/parted_8.html
I am sure there are better ways to do this than dd. I tried that some ten years ago on identical machines and it did work, but was slow. I believe nowadays it makes more sense to be using tools like:
Partimage. I tried this a while ago and it was quite good.
Clonezilla. I've only heard it does the job, but have no observations of my own.
For more info, check this link.
dd will work, but is very slow because you'll have to copy over the whole disk, not just the data. I install hundreds of systems all the time and use SALI and System Imager. I use SALI to actually install the images and System Imager to manage variations of hardware and images. There's several ways to do it in SALI, but the standard method is via a pxeboot loader. But that's not required.
I'm trying to port a wide Visual Studio (2008) Project to Linux System.
Do somebody know if it exist a way to easly "transform" the .vcproj file into a makefile?
Easiest would be to just learn how to write your own Makefile. It's quite simple.
But other than that you could try http://www.codeproject.com/Articles/28908/Tool-for-Converting-VC-2005-Project-to-Linux-Makef
Maybe this can help you, but you need to handle whit you outputs in the original code
Make-It-so
http://code.google.com/p/make-it-so/
or
sln2mak
http://www.codeproject.com/Articles/28908/Tool-for-Converting-VC-2005-Project-to-Linux-Makef
i hope this can help you
You can use Winemaker, which is part of WINE: something all major distributions already include.
On Fedora, which use yum, you can, as root, run yum install /usr/bin/winemaker to install it. This will probably also work on other yum based operating system, but you may have to provide another path, if winemaker is packaged to install in /usr/bin (which I doubt will be the case).
Once you have converted the project, consider using Autotools instead -- it's, in my experience, by far the simplest build tool available and is very easy to learn and use. Just don't be scared to poor documentation you will often find lying around. The only files you have to edit are configure.ac and Makefile.am files.
I would like to generalize a build system to compile on several (somewhat similar) platforms. What is a good method for determining the type of host that the shell script or Makefile is running on. I would like to distinguish between mac and linux, but also different specific distributions of linux (e.g. RHEL, Ubuntu). Cygwin is not important for me, but if you include it in your response I am sure others will find it valuable.
The rationale may include using the host type to fetch and install the correct versions of binary packages when it is more convenient to do so than compile from source. In addition, some commercial software is binary-packaged for specific distros, so part of the motivation is to grab the right binary.
Thanks,
SetJmp
Autotools to the rescue. It has tons of macros that help you do this kind of stuff.
http://www.lrde.epita.fr/~adl/autotools.html
uname -a to distinguish major *nix variants
Not so sure what the best way to distinguish red hat from ubuntu would be - could look for package managing tools and query installed packages, eventually helping you narrow down different debian derivatives, etc. There's probably something more obvious and up front though.
linux variants generally store distro information in /etc/issue.
most kernels will put info in /proc/version
It's not completely straightforward. You can use uname to find out the general parameters but to differentiate between distributions is a harder task. Maybe you should consider using something like autoconf to generalise your build system?
Just in case you're using Qt, there's this really nice set of defines, Q_OS_*, that guide you to the Operating System you're compiling on:
Q_OS_AIX
Q_OS_BSD4
Q_OS_BSDI
Q_OS_CYGWIN
Q_OS_DARWIN
Q_OS_DGUX
Q_OS_DYNIX
Q_OS_FREEBSD
Q_OS_HPUX
Q_OS_HURD
Q_OS_IRIX
Q_OS_LINUX
Q_OS_LYNX
Q_OS_MAC
Q_OS_MSDOS
Q_OS_NETBSD
Q_OS_OS2
Q_OS_OPENBSD
Q_OS_OS2EMX
Q_OS_OSF
...
They are defined in QtGlobal. There are even defines that help you figure out the compiler used Q_CC_* or the target Windowing System Q_WS_*.
But if you're not using Qt and want to go for a generic method, you most likely have to fall back to the Autotools package or CMake.
Determining Linux distributions is pretty tricky, but not hard. You first have to figure out what distributions you care about and then make all kinds of distribution specific file/configuration checks like in this example for the ones you've chosen, since you can't really support all of the myriad of Linux distros available out the. :-)
As for the Mac side i'll let the Mac experts answer, but it shouldn't be that hard, since at least the diversity issue is out of the question.
I'm interested in contributing to a Linux distro, but regarding the various distro's developer communities, I'm having a bit of trouble figuring out which one I'd most like to join.
What languages I know: C, C++, Lua, Python, and fairly familiar with Perl (though I wouldn't say I "know" it). In particular, I have very little experience with x86 assembly besides hacking stuff together for performance tweaks, though that will be partially rectified soon.
What I'm looking for: A community that provides plenty of opportunities for developers to work on various aspects of the distribution. To be honest I'm most interested in reading and working on the kernel source (in which case the distro doesn't matter), but it's pretty daunting and I figure getting into the Linux community and working with experienced Linux developers might give me a better idea of how to jump into the guts(let me know if this is bogus, or if you have any advice regarding that).
So...
Which distro has the "best" developer community in terms of organization, people who are fun to work with, and opportunities to contribute?
I've read various "Contributing to XXX" pages and mailing lists for distros like Ubuntu, OpenSuse, Fedora, etc. but I'd rather get a more personal testament from an actual developer.
Unless you have a specific desire to learn the ins and outs of various packaging formats you would probably be better off contributing directly upstream to applications/libraries that you find interesting. While individual distributions often have a few management applications that are unique(ish) to them most core applications and libraries are shared between them.
As you have expressed an interest in guts it would make sense to stick to one of the main community distros (Fedora and Ubuntu/Debian) as the rest tend to be variations on a base distro. The other option is to choose a source based distribution which have a number of advantages to developers although you may find yourself spending a bit of time keeping your machine trim.
As I'm a developer I personally use Gentoo which gives me a number of things:
Rolling release: New versions of applications are generally available soon after release
Stable/Unstable mix: I can run stable core with bleeding edge on upstream packages I care about
Development ready: Any installed package is by default a "dev" package, the distinction between buildtime/runtime dependencies is blurred
Packaging is easy: If it's a simple as "configure/make/make install" writing and ebuild is very easy.
Contribution is easy: Contributing new ebuilds is fairly painless, from there you can get as involved as you like
Of course there are downsides, not least of all your machine spends a considerable amount of time building things and if your run a large selection of "unstable" packages you may find you occasionally need to fix-up your machine. However I find these disadvantages minor compared to giving me an up to date platform with which to contribute to upstream from.
If you want to work with the kernel then you shouldn't be picking a distribution, but rather working upstream.
Somebody correct me if I'm wrong, but I think that contributing to Ubuntu can be very easy and fun if you use Launchpad. I haven't tried contributing code, but I contribute translations and file bugs on some projects.
I want to know whether we need to download GTK for making graphical interfaces in C on linux, since i have read somewhere that it is by default installed.
You have a number of choices for a GUI on Linux. Most distros ship with x11 at least, though you will have to design the controls yourself. GTK and QT are two common toolkits, which have their own look and feel (of course QT isn't C).
There exist a lot of library to do GUI in linux. Some are installed by default depending on the Distribution and your environment (eg: gnome come with GTK).
You can also want to use other library like qt... (with may required an installation if it is not provided in your distribution, but nowadays, It is really easy to install such library eg: apt-get, yum, rpm...)