I'm trying to package the current stable version of FMOD for Debian. My issue is that there are separate source tarballs for the amd64 and x86 architectures. How to handle this case?
I first tried to create separate fmodex32 and fmodex64 packages which both provide a virtual package called fmodex but this approach failed as fmodex-dev should require fmodex in its exact version. Dependencies on specific versions are never satisfied by virtual packages.
Related
I am making an operating system with Yocto. I created new meta, new layer, new recipe and new machine. It was working fine until I tried to include packages already compiled for debian. Normally, I was installing these packages with the apt-get command after flashing the image, but as the number of packages increased, they started to conflict with the packages that came with the image and compiled with bitbake, so I am trying to add these packages as a recipe.
Can I create recipe directly from .deb file or .dsc file? If I can't create it, how can I find the source code and how can I create a recipe from the source code?
I'm currently using the OpenEmbedded dunfell version, but I'm planning to switch to the kirkstone version. Since I'm using dunfell version, I'm looking at debian's stretch version packages. Which version packages of debian should I look for when I switch to kirkstone version?
I am compiling for armhf architecture on Intel 64 bit Ubuntu 18.04. I'm compiling for a custom board.
These are the packages I'm trying to install for now (I think I can install similar packages if I can install them with a recipe):
xbindkeys
libcrypto++6
libcurl3-gnutls
default-jre-headless
libccid
libpam-pkcs11
pcscd
libacsccid1 (This is special because it only has deb package. There is no source code or dsc file.)
Whilst Yocto Project and OpenEmbedded can output deb packages they are only compatible with the DISTRO setting that built them in OE. Packages from Debian are not compatible.
You can look at https://layers.yoctoproject.org/ to search for recipes in other layers which may be able to build what you need once those layers are added.
Where you can't build from source you may be able to extract files from a Debian deb and turn it into a different deb that might work with OE but it assumes the binaries are compatible and they may or may not be depending on how you've configured your build. This isn't recommended.
I am trying to install SDL2 on Linux Ubuntu 18.04. However there are 2 types of packages available on the repository, the 'normal' library version and the development files version.
libsdl2-2.0-0/bionic-updates,bionic-security 2.0.8+dfsg1-1ubuntu1.18.04.4 amd64
Simple DirectMedia Layer
libsdl2-dev/bionic-updates,bionic-security 2.0.8+dfsg1-1ubuntu1.18.04.4 amd64
Simple DirectMedia Layer development files
What I am asking is are there differences between the two version for developing application/game using SDL2 and which one should I install if I am just starting to learn SDL2?
Ubuntu (and other Linux distributions) often divide up packages this way: the first package contains libraries and executables needed to run something compiled with the package (SDL2 in this case), the dev packages contains the headers, additional libraries or config files needed to compile a program with package. You want to install both; normally installing the dev version of the package will pull in the other as a dependency.
You will need both, most likely :)
The lib package contains the binary SDL library. That's needed to run a program.
But in order to develop an application, you need the C header files to include in your source code - assuming that you want to create a program in C or C++. The compiler needs these files to 'see' the functions provided by the lib.
If you want to use SDL library in a different way, you could also use python and python-pygame-sdl2.
In Debian Jessie/8 there is GCC 4.9.2.
I need the latest version, GCC 6.x.
Is it possible to install it through Synaptic from the testing repository (i.e. the binary, not the source), in parallel with the old version?
Is there a risk of conflicts among libraries/headers/... Are they going to be stored in separate directories like gcc-4.9/ gcc-6.0/ ...?
So far, I have only been able to install a second compiler building it from source, in its own directory.
Yes sure.
If two packages conflict (e.g. because they contain the same file), then he package manager (apt, aptitude, synaptics, ...) will refuse to install both at the same time.
So you can install any packages in parallel, as long as the package manager allows you to.
E.g. on my system, I have installed both gcc-5 and gcc-6.
Technically, the Conflict is expressed explicitely by the maintainer of a package.
Obviously they cannot track all possible packages in the world, but instead really concentrate on the target release (e.g. packages from jessie properly conflict with other packages from jessie, but not necessarily with packages from woody (aka Debian GNU/Linux 3.0)).
Since upgrading between consecutive releases (e.g. jessie -> stretch) is considered crucial, you can also rely on proper Conflicts when installing testing (aka next-to-be-stable) packages on stable systems.
OTOH, there might of course be bugs in the packaging, where the Conflicts are not properly expressed (if you find one, don't hesitate to report it).
If this happens to happen, the installation will fail, and you can revert the change.
So it's pretty safe to try to install whatever packages are available in Debian.
(However, I wouldn't put that much trust into 3rd party repositories)
I have a project that runs on Debian and uses many packages provided from the Debian repositories.
Because of demand, I've looked into porting the project to CentOS, but found that many of the packages I require are completely missing - at least 10 dependencies would have to be compiled manually at install time on the users machine.
My question is, what is the best way to create an installer for the user's machine? Should I use automake tools (with the standard ./configure, make, make install), to compile the required libraries, or is this a non-standard approach. Note that my app doesn't actually need to be compiled since it is written in Python, so is it weird to do a "make", when you're not compiling your own app?
Should the configure script just warn the user that package X is missing, and let them handle the rest?
Should I roll my own dependency checker by runng pkg-config manually a few times for each library required, and exit if something is missing?
I'm quite new to this, so any tips to get me moving in the right direction are appreciated.
Edit: I am familiar with RPM and yum for red hat base distros, but CentOS is missing many multimedia packages that I require. An example of one of my package dependencies is "liquidsoap" which is a programmable audio engine: http://savonet.sourceforge.net/
This is available on Debian, but not Redhat/Centos
See this link on CentOS package management.
http://wiki.centos.org/PackageManagement/Yum
CentOS is redhat based and does not use .deb packages by default. However apt package management has been ported to tons of platforms, you may be able to use a port for centOS
If you use YUM whatever packages you need will be there for your application as redhat distros need all the same things that any other distro does.
EDIT: To get the details out of comments
Packages not available on the target platform either have to be built (possibly as a port) on the target platform and then shipped in the ported package (in this case YUM), or code needs to be modified and forked to use packages which already are available on the target platform. The choice depends on which is worse, or which is even possible given your constraints.
I am working through my 7th recompile of the same software. There are no pre-built packages available, and it's a long compile time. Is there a way to take what I compile and package it up so that I don't have to continually build it right from source?
EDIT: CentOS 6 for the OS if that matters.
You should have a look at CDE. From its website :
CDE (formerly known as CDEpack) automatically packages up the Code, Data, and Environment required to deploy and run your Linux programs on other machines without any installation or configuration. CDE is the easiest way to completely eliminate dependency hell.
So it will compile your program and include all the dependencies in the resulting package as well. The resulting package should be able to run on any modern x86 Linux distribution, so you won't have to continually build it right from source.
checkinstall, which is based on installwatch, is able to create various packages including .deb (Debian, Ubuntu, ...), .rpm (Red Hat, Fedora, SuSE, ...) and .tgz (Slackware) suitable for your distribution's package manager.