I am using cpack to create a Debian package. My package needs libgit2 at runtime. I have
set(CPACK_DEBIAN_PACKAGE_DEPENDS "libgit2")
in my CMakeLists.txt file, but the installer fails to find libgit2.
I found libgit2-27 is available but seems that the number 27 is going to change in the future.
How can I ask installer to install "libgit2-" + <any number higher than 24>"?
Similar as described in the Debian documentation:
set(CPACK_DEBIAN_PACKAGE_DEPENDS "libgit2-25 | libgit2-26 | libgit2-27")
Related
Is there a way to backup the previous installed version of a .deb package generated by cpack?
I have a project that i need to deploy manually on multiple equipments in a live production site. To minimize error and time spent deploying, i would like to use cpack and a .deb generator to create a package.
But i also want to keep the previous installed version, and config files for fast roll-back.
I have already have a package with can be successfully installed with it's configuration files. Contained in a folder with the version as a name. But when I install the new version it automatically removes the older version. Is there a way to stop the installer from doing this?
I've solved my problem by moving away from the .deb package and I'm instead using the .stgz package with a custom script.
To create this script have a cmake folder in your project for cmake scripts. This is done by setting following line into your cmake file.
list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/Resources/CMake")
Copy a CPack.STGZ_Header.sh.in file into this directory. Normally you will find one in /usr/share/cmake-3.10/Modules/.
Edit this file at will to reflect it what you want to do. Make sure to leave the 3 line that really unpack your package untouched.
is there a portable edition of perl 6 ?
or its possible to compile it and install some modules zip all to one directory , and then unzip on different machines having the same OS ?
If both computers have the same filesystem layout -- maybe. At the very least all absolute paths to these items would need to be identical or else you'd have bad precompiled files everywhere.
Of course this is not a very practical solution ( how many computers do you have with the same home directory ), but for instance you could ( and indeed we used to ): build rakudo inside of travis-ci, push the entire folder to a private repo, and then could pull that repo down from other travis instances to get an already-built version of the very latest rakudo release.
May be you can run Perl 6 on Android: https://github.com/termux/termux-packages/issues/1324, but current there is no package for Perl 6 on Termux.
Some time in 2019 Rakudo gained the ability to be relocated. Since the 2019.11 release pre-compiled, relocatable binaries are provided for every release. They can be downloaded from rakudo.org.
So you can download such an archive, extract it to some folder, install modules with the included package manager zef, bundle it up with your own code, zip it and it will work on any computer (given it's the same architecture and OS), in any folder.
I run: conan install Boost/1.64.0#conan/stable, and it fails.
Output:
C:\temp>conan install Boost/1.64.0#conan/stable
Boost/1.64.0#conan/stable: Not found in local cache, looking in remotes...
Boost/1.64.0#conan/stable: Trying with 'bintray'...
Boost/1.64.0#conan/stable: Trying with 'conan.io'...
ERROR: Unable to find 'Boost/1.64.0#conan/stable' in remotes
Trying other package, works:
C:\temp>conan install fmt/4.0.0#bincrafters/stable
fmt/4.0.0#bincrafters/stable: Not found in local cache, looking in remotes...
fmt/4.0.0#bincrafters/stable: Trying with 'bintray'...
fmt/4.0.0#bincrafters/stable: Trying with 'conan.io'...
Downloading conanmanifest.txt
[==================================================] 121B/121B
Downloading conanfile.py
[==================================================] 1.8KB/1.8KB
fmt/4.0.0#bincrafters/stable: Installing package
Requirements
fmt/4.0.0#bincrafters/stable from conan.io
Packages
fmt/4.0.0#bincrafters/stable:63da998e3642b50bee33f4449826b2d623661505
fmt/4.0.0#bincrafters/stable: Retrieving package 63da998e3642b50bee33f4449826b2d623661505
fmt/4.0.0#bincrafters/stable: Looking for package 63da998e3642b50bee33f4449826b2d623661505 in remote 'conan.io'
Downloading conanmanifest.txt
[==================================================] 938B/938B
Downloading conaninfo.txt
[==================================================] 491B/491B
Downloading conan_package.tgz
[==================================================] 159.8KB/159.8KB
fmt/4.0.0#bincrafters/stable: Package installed 63da998e3642b50bee33f4449826b2d623661505
Any idea why the package isn't found?
How to debug it?
Conan is a decentralized package manager (kind of git-like style), so it can have many remotes. By default it comes configured with 2 remotes:
conan-transit: Is a read-only copy of the old conan.io repository, which contains many different Boost packages, from different authors. Quality is variable, so some packages might work only for certain OS, or might fail for some configurations.
conan-center: It is a moderated/reviewed repository, package creators can submit inclusion requests to share their packages with the community.
So far conan-transit contains several Boost/1.64 packages, so can check it with:
$ conan search Boost* -r=conan-transit
$ conan search Boost* -r=conan-center
As you can see the package you are trying to install doesn't exist in these repositories.
As I said above, conan is decentralized, so you can use different remotes. For example, the "bincrafters" community has a bintray repo that can be added with:
$ conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan
$ conan search Boost* -r=bincrafters
You will see they have a large number of Boost/1.64 packages, because they have created a modularized version of boost, in which every library lives in a different package, so you only get installed what you need.
UPDATE: Packages in the central repository are being renamed by the community to lowercase. Try with boost lowercase in the above if necessary.
I have a CMake project to build multiple shared libraries and tools, most of these under subdirectories:
add_directory(libFirst)
add_directory(libSecond)
add_directory(myTool)
# etc...
The install(TARGET "someTarget" COMPONENT "someTarget" ...) rules are in the respective subdirectory/CMakeLists.txt files.
I would like to generate Debian packages for all of these using a make package command from the build directory. I have CPACK_DEB_COMPONENT_INSTALL set to ON.
The problem I'm facing, is that not all of the targets have the same VERSION and/or SOVERSION. For example, libFirst is at version 1.0.0.0 and libSecond is version 4.3.0.0. This means that the generated packages should also have different version, but the only way I've found to specify the version is to specify the CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH variables (and perhaps the internal CPACK_PACKAGE_VERSION variable), which set the version for all generated packages.
Is there a way to set package versions per-component, for example by setting some variables similarly to the other CPACK_COMPONENT_<COMPONENT>_* or CPACK_DEBIAN_<COMPONENT>_* variables?
I don't think this is possible at the moment but I have created a merge-request (https://gitlab.kitware.com/cmake/cmake/merge_requests/2305) which provides this functionality.
I hope it will get approved but in the meantime you can locally change your CPackDeb.cmake as shown in this diff: https://gitlab.kitware.com/cmake/cmake/merge_requests/2305/diffs. The default location of that file is in /usr/share/cmake/Modules/CPackDeb.cmake.
I am trying to build a .deb package for an application my company (and me) have been developing.
I'm trying to create a 64bit package on my 32bit ubuntu (12.04 LTS) using dpkg-buildpackage and I get the following warnings/errors:
dpkg-shlibdeps: warning/error: couldn't find library X needed by Y.so (ELF format: 'elf64-x86-64'; RPATH: 'some/path/that/does/not/exist')
When X is one of our compiled shared libraries, we get a warning. When it's a system library (like libgcc_s.so.1 and libstdc++.so.6) we get an error.
Why is the RPATH refers to a path that does not exist?
By the way, when I make a 32bit package (on our files that were compiled for 32bit of course) it only shows warnings (only about our proprietary .so files) but creates the .deb file.
If I could, I would have posted my debian folder content but I cant take files out of our network. I can type the relevant parts if its needed.
You need to install the 64-bits version of the library with apt-get (actually anything do, but this is the most easy):
sudo apt-get install libyouneed-dev:amd64
The trick here is the :amd64, which tells the package manager to install the 64-bit version of that package. The same applies for 32-bits libraries in 64-bit systems. It's called multiarch.
The package is looking at that path because that is where the libraries of 64-bits (or 32-bits) gets stored, but since you don't have it installed the path do not exist.
Install an amd64 chroot environment and build your package in there. This way you avoid the various multi-arch pitfalls, with the added benefit of having a clean, reproducible build.
There is a tool that makes this very easy: mk-sbuild.
You need to install ubuntu-dev-tools and sbuild.
Then, run mk-sbuild --arch=amd64 precise, which will setup the build environment for you.
Add yourself to the sbuild group: adduser <your user name> sbuild
Log out and log back in so your group membership will be reflected.
You can then build your package in the chroot:
sbuild -d precise --arch=amd64 name_of_package.dsc
This assumes you've already build the source package with debuild -S or similar.