I am building a debian package using dpkg.
The package has a dependency on libvirt which is not desired.
The rules file does not specify this dependency, but it is added by dpkg, I suppose due to some calls to libvirt-dev at build time.
However my package works fine without libvirt. As such, libvirt is a "Recommended" package but not "Required". How do I override this dependency and make sure it is not present in my final deb file ?
Hard to know without seeing your actual package, but I'd guess that you have a binary or shared library which is linked against libvirt. That would cause dh_shlibdeps to include libvirt in the ${shlibs:Depends} substvar.
If that's your problem, then the right fix depends on what's getting linked to libvirt. It should be straightforward to determine; just run ldd on each binary or shared library object in your package, and grep for "libvirt".
If the thing linked against libvirt is only incidental to the package, and isn't part of the main functionality, then using Recommends: would indeed be the right thing. To make dh_shlibdeps exclude that object from its dependency scanning, give it a -X option. Example target for debian/rules, assuming debhelper7-style packaging:
override_dh_shlibdeps:
dh_shlibdeps -Xname_of_your_object_to_exclude
If the thing(s) linked to libvirt actually are an important part of the package functionality, then the generated libvirt dependency is appropriate. If you still don't want it, you'll need to work out how to avoid linking against libvirt during your build.
Related
I am working on a Symfony 2.7 project. I ran composer update --dry-run to check which packages could need an update. Composer notified me about a deprecated package:
Package symfony/icu is abandoned, you should avoid using it. Use
symfony/intl instead.
I simply removed the dependency from the composer.json file and ran composer update --dry-run again. The message did not show up again, symfony/icu was uninstalled and symfony/intl was not installed.
Fine, this means that non of the other requirements depends on symfony/icu or symfony/intl. But can I be sure, that non of my own code requires any of these packages?
I created the project white a while ago and I do not remember why I added symfony/icu. I is possible, that the code that once required this packages has been removed, but I am not sure.
I used grep to search for any import of symfony/icu and found nothing. However that does not guarantee, that the package is not uses somewhere within my code, does it?
Is there any way to check if there are any dependencies within the complete Symfony project that require a specific package?
Check for every package? :(
I think you can do this only with automated testing.
There are no tools (I'm aware of) to detect whether some package is required to complete missing classes. There are also optional dependencies (package works without them, but with them will add some new features), so you will find missing classes but not required to run application.
How to check one package? :)
You heading right direction with grep. Yet rather look for namespace instead of package name. Package name is not always 1:1 to package namespace.
I would look for:
repo on Github: https://github.com/symfony/icu
open some file: https://github.com/symfony/icu/blob/1.2.x/IcuRegionBundle.php
find namespace
namespace Symfony\Component\Icu;
then search for "Symfony\Component\Icu" in code in PhpStorm or grep
I think the cleanest way is to start with composer and tell it dump all packages that caused your package to install:
For example, I'm trying to figure out why monolog/monolog is installed:
$ composer depends monolog/monolog
symfony/monolog-bundle 2.11.1 requires monolog/monolog (~1.18)
So monolog/monolog was installed because of symfony/monolog-bundle.
As you said you might have unintentionally use a package that's a dependency of another package so you didn't add it to your dependencies.
I'd use grep just as you did to search my source code. Just note that it's better to search for an actual class name, not the package name. Searching for package name would give you composer.json files but that's easier to analyze with composer depends than grep:
$ grep --include=\*.php -rnw './vendor' -e 'use Monolog'
./vendor/monolog/monolog/src/Monolog/ErrorHandler.php:16:use Monolog\Handler\AbstractHandler;
./vendor/monolog/monolog/src/Monolog/Formatter/ChromePHPFormatter.php:14:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/FluentdFormatter.php:45: throw new \RuntimeException('PHP\'s json extension is required to use Monolog\'s FluentdUnixFormatter');
./vendor/monolog/monolog/src/Monolog/Formatter/GelfMessageFormatter.php:14:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/HtmlFormatter.php:13:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/NormalizerFormatter.php:34: throw new \RuntimeException('PHP\'s json extension is required to use Monolog\'s NormalizerFormatter');
./vendor/monolog/monolog/src/Monolog/Formatter/WildfireFormatter.php:14:use Monolog\Logger;
This command searches all *.php files and dups also line numbers containing Monolog.
Unfortunately, the these two methods just analyze your code post-mortem. Really the best way to avoid dealing with this is to write unit tests. Then clone your fresh repository, install dependencies with composer install and run tests. This should guarantee that your code is run in isolation from any other unwanted dependencies.
I would want to get the list of installed packages that depend on gcc (installed with homebrew). When I try:
brew uses --installed gcc
it gives no result. And if I check e.g. r's dependencies with brew deps r, it returns gcc (among others). So I assume brew uses should at least return the value r.
Did anyone encounter a similar problem and could shed some light on this?
This is not an authoritative answer, but it appears to me that this is because r depends on :fortran, which is some kind of virtual dependency that can be resolved in different ways. brew deps answers the question, what would I need to install before installing this formula. And in your case it decides that installing gcc is a way to satisfy the :fortran requirement. But the reverse is apparently not supported: It doesn't know just from looking at gcc that this can be used to resolve the virtual dependency :fortran. This is somewhat plausible if one considers the way that virtual dependencies are implemented in Homebrew. Usually, it just looks around in the file system to see if a required binary is available (including ones supplied outside of Homebrew), but it doesn't establish a formula dependency link once it finds a candidate.
(In fact, this case might be even more complex. If you look at brew deps r --tree, you will see that the dependency is actually on :gcc, which is another level of virtual dependency.)
Although not directly related to your question, also note that deps by default is recursive but uses is not. So in order to get a symmetric picture, you'd need to use deps -1 or uses --recursive.
I am trying to compile Network.HTTP (http://hackage.haskell.org/package/network) on win32/cygwin. However, it does fail with following message:
Setup.hs: Missing dependency on a foreign library:
* Missing (or bad) header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Unfortuntely it does not give more clues. The HsNet.h includes sys/uio.h which, actually should not be included, and should be configurered correctly.
Don't use cygwin, instead follow Johan Tibells way
Installing MSYS
Install the latest Haskell Platform. Use the default settings.
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo.
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into C:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of C:\msys\1.0, unpack it there, and then rename the copy back to C:\msys\1.0.
Add C:\Program Files\Haskell Platform\VERSION\mingw\bin to your PATH. This is neccesary if you ever want to build packages that use a configure script, like network, as configure scripts need access to a C compiler.
These steps are what Tibell uses to compile the Network package for win and I have used this myself successfully several times on most of the haskell platform releases.
It is possible to build network on win32/cygwin. And the above steps, though useful (by Jonke) may not be necessary.
While doing the configuration step, specify
runghc Setup.hs configure --configure-option="--build=mingw32"
So that the library is configured for mingw32, else you will get link or "undefined references" if you try to link or use network library.
This combined with #Yogesh Sajanikar's answer made it work for me (on win64/cygwin):
Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the
C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe
(Run
export PATH="/cygdrive/.../ghc-7.8.2/mingw/bin:$PATH"
before running cabal install network in the Cygwin shell)
I have a software system having 30+ Open Source packages, most of them using GNU Autotools suite.
Are there tools to automatically generate package-to-package dependency graph? I.e. I'd like to see something like gst-plugins-good -> gst-plugins-base -> gstreamer -> glib.
I don't think so, but you could probably whip something together with this knowledge:
Scan the file named either configure.ac or configure.in in the package's root directory.
Look for a string of the form PKG_CHECK_MODULES([...],[...]...)
The second argument of that macro consists of package requirements of the form package or package >= version separated by whitespace.
The requirement string might not be the same as the package tarball name; a tarball that contains package.pc or package.pc.in provides the package package.
This only works for dependencies that use pkg-config. Some don't and you'll need to keep track of those dependencies by hand.
Probably not, because this is a hard problem. If there were only one way to build a package, it might not be too bad, but in general this isn't the case. You have the --enable-foo and --with-foo options that you can pass into configure. Those are sometimes package dependent also, requiring more packages. Most Linux distros (I think but am not completely sure) maintain these sort of dependency lists for yum or zypper or apt or whatever the package manager is by hand, and only one layer deep, leaving it up to the package manager to traverse the graph. The packages for the distro are only built one way. It's not unusual for these lists to be broken, also.
Does R have a dependency management tool to facilitate project-specific dependencies? I'm looking for something akin to Java's maven, Ruby's bundler, Python's virtualenv, Node's npm, etc.
I'm aware of the "Depends" clause in the DESCRIPTION file, as well as the R_LIBS facility, but these don't seem to work in concert to provide a solution to some very common workflows.
I'd essentially like to be able to check out a project and run a single command to build and test the project. The command should install any required packages into a project-specific library without affecting the global R installation. E.g.:
my_project/.Rlibs/*
Unfortunately, Depends: within the DESCRIPTION: file is all you get for the following reasons:
R itself is reasonably cross-platform, but that means we need this to work across platforms and OSs
Encoding Depends: beyond R packages requires encoding the Depends in a portable manner across operating systems---good luck encoding even something simple such as 'a PNG graphics library' in a way that can be resolved unambiguously across systems
Windows does not have a package manager
AFAIK OS X does not have a package manager that mixes what Apple ships and what other Open Source projects provide
Even among Linux distributions, you do not get consistency: just take RStudio as an example which comes in two packages (which all provide their dependencies!) for RedHat/Fedora and Debian/Ubuntu
This is a hard problem.
The packrat package is precisely meant to achieve the following:
install any required packages into a project-specific library without affecting the global R installation
It allows installing different versions of the same packages in different project-local package libraries.
I am adding this answer even though this question is 5 years old, because this solution apparently didn't exist yet at the time the question was asked (as far as I can tell, packrat first appeared on CRAN in 2014).
Update (November 2019)
The new R package renv replaced packrat.
As a stop-gap, I've written a new rbundler package. It installs project dependencies into a project-specific subdirectory (e.g. <PROJECT>/.Rbundle), allowing the user to avoid using global libraries.
rbundler on Github
rbundler on CRAN
We've been using rbundler at Opower for a few months now and have seen a huge improvement in developer workflow, testability, and maintainability of internal packages. Combined with our internal package repository, we have been able to stabilize development of a dozen or so packages for use in production applications.
A common workflow:
Check out a project from github
cd into the project directory
Fire up R
From the R console:
library(rbundler)
bundle('.')
All dependencies will be installed into ./.Rbundle, and an .Renviron file will be created with the following contents:
R_LIBS_USER='.Rbundle'
Any R operations run from within this project directory will adhere to the project-speciic library and package dependencies. Note that, while this method uses the package DESCRIPTION to define dependencies, it needn't have an actual package structure. Thus, rbundler becomes a general tool for managing an R project, whether it be a simple script or a full-blown package.
You could use the following workflow:
1) create a script file, which contains everything you want to setup and store it in your projectd directory as e.g. projectInit.R
2) source this script from your .Rprofile (or any other file executed by R at startup) with a try statement
try(source("./projectInit.R"), silent=TRUE)
This will guarantee that even when no projectInit.R is found, R starts without error message
3) if you start R in your project directory, the projectInit.R file will be sourced if present in the directory and you are ready to go
This is from a Linux perspective, but should work in the same way under windows and Mac as well.