I have a couple of NuGet package questions that I cannot seem to locate an answer for.
First, most packages have one or more dependencies on other packages. These dependencies are listed with a minimum (and sometimes, maximum) version number. What is an easy way to determine this range when creating packages? For example, my code depends on a particular package. If I install the earliest version, my code will not compile. If I install the latest version, my code will compile. Somewhere along the line (between the oldest and newest version), the code I need to reference was added. How do I determine where (read, what version) this was added in a particular package so I can set the minimum version?
Second, when I set a package dependency, is it an all or nothing type of thing? By that, I might need only an assembly or two from a package but not the rest. Is there any way to get rid of the extra stuff? As an example, the package I use has an indirect dependency on Newtownsoft.Json. However, my code does not use this assembly in any way. Should I just ignore this? I don't want extra assemblies that are not required floating around.
For your second question, package dependency supposed to be essential for the dll to compile, so its strange that some of the dlls are unnecessary. But if indeed its the case, there is no way to avoid it, in the package install process, because the NuGet recognize all the dll files under the lib folder in the nuget package, and add them as reference.
But you can delete the reference from the project config file (.csproj), and in the package restore process, nuget only download and extract the nuget package. and dont touch the .csproj files.
I didn`t understand exactly your first question, but you can enforce the nuget package version specific for your needs, link: http://docs.nuget.org/docs/reference/versioning
Related
I need the source package for the mingw64/mingw-w64-x86_64-gcc-libs-8.2.0-3 package. I believe this is generated from the mingw-w64-x86_64-gcc source package. Looking in the repository I can find mingw-w64-gcc-7.3.0-2.src.tar.gz but nothing for gcc-8.*.
Most other packages have a simple relationship between binary and source package names. In a few cases (GCC is one) a single source package is used to generate multiple binary packages. However the naming is usually fairly obvious, and version numbers stay the same. I can't find any GCC-related source packages with the "8.2.0" version number.
Does anyone know where to get the source for the gcc-libs mingw package from?
You might want to look at here. You can find GCC 8.1.0.
Open an issue on https://github.com/Alexpux/MINGW-packages/issues
Apparently the maintainer forgot to upload the source package, or some script is failing.
I maintain a commercial, binary package for debian, ubuntu, & etc. and have gotten complaints about "bad package quality" from the Ubuntu installer. The root cause of this appears to be that the package installs files in the /opt and /etc/opt directories which apparently throws lintian into a hissy fit. As I understand the purpose of these directories, they are meant to serve the needs of "Add-on" applications although I have yet to see any definition of what "add-on" is supposed to mean. I have attempted to create a lintian override file for my package in the /usr/share/lintian/overrides directory and, when I do so, I get the following report from Lintian:
N: Some overrides were ignored, since the tags were marked "non-overridable".
N: The following tags were "non-overridable" and had at least one override
N: - dir-or-file-in-opt
Is there any way around this apparent obstinacy?
If you're using debhelper to build your package, lintian overrides for the binary packages should go in the debian folder with the filename [package].lintian-overrides. This ensures the overrides make it into the proper directory on package installation. (For source packages, overrides go in the file debian/source/lintian-overrides.)
That said, short of not putting your files in /opt, I'm not sure there's a way to completely get rid of the dir-or-file-in-opt lintian complaint. Though, I'm not sure it's necessary since, to my knowledge, the ubuntu/aptdaemon lintian profile (which disables the dir-or-file-in-opt tag) is used in most of the situations in which lintian would be run automatically during/before package installation. That's probably not quite the answer you were hoping for, but I hope it's helpful nonetheless!
Sources:
Debian New Maintainers' Guide, section 5.14
Lintian User's Manual, section 2.4
Cendio ThinLinc bug #5232
How do I find the source of the code I am importing. Like if I do
λ <Prelude>: import Graphics.EasyPlot
λ <Prelude Graphics.EasyPlot>:
How do I find that code. I do not mean an online copy of the code (Google is very good at indexing Hackage by that) but where it is on my system that I can edit. The reason is that it is a bit buggy, and I want to try and fix it. (I might submit a patch, but I just want to fix it for my own use first.)
As #ThomasDuBuisson mentioned, you many not necessarily find that on your system. One thing which I generally do is fetch it using cabal:
cabal fetch package-name
It downloads the tarballs of the package. Once you have fetched it, the entire source will be under the path where cabal puts it. In my case, it is (/home/sibi/.cabal/packages/hackage.haskell.org/package-name ). You can then untar and then build it from the cabal file which is already present there.
That being said you should probably using the version control system which the project is using as #bheklilr pointed out.
I have developed a module (M.hs) which depends upon 3 other modules (A.hs, B.hs and C.hs). Now I want to use the module M across multiple other projects. So I have to install this module. But for learning purpose I don't want to use cabal, I want to do it manually. I want to install it in my home dir.
What is a proper course of action? Which files to be created, copied? where? How to use this module in other project?
Additional info:
I am using Debian 6
I am using GHC 6.12
You say you don’t want to use cabal, but would you use Cabal?
cabal is the name of the command line tool provided by cabal-install which can download packages from Hackage and resolve dependencies.
Cabal is the library that Haskell code uses to drive the compilation (e.g. pre-process files, build in the right order, build variants, generate documentation) and install into the right location.
I would not recommend not using Cabal, even for learning purposes, until you want to write a replacement for it. But if you really want to do it, here is the rough outline, with enough details to figure out for a good learning experience:
Build your files with -package-name yourpkgname-version.
Link the generated files to form a libyourpkgname-version.a file.
Create a package configuration file like /var/lib/ghc/package.conf.d/mtl-2.1.2.conf, and pay attention to name, `exposed-modules, import-dirs, library-dirs and hs-libraries
Register package by passing it to ghc-pkg register
I am trying to build an application with OpenSync 0.4 (0.3.9 indeed) dependency.
In the project's configure.ac the opensync library is written as libopensync1. However, this doesn't build on my Gentoo system. Changing libopensync1 to libopensync does fix the issue for me.
I searched with Google and found that libopensync1 is used in some distributions, while libopensync in others. So how to resolve this issue in configure.ac?
Thanks.
The macro AC_SEARCH_LIBS does what you need. (There is much heated debate about whether or not pkg-config should ever be used. If you choose to rely on it, ptomato gives a reasonable approach.) Simply add this to your configure.ac:
AC_SEARCH_LIBS([osync_mapping_new],[opensync1 opensync],[],
[AC_MSG_ERROR([can't find opensync])])
This will first look for a library named opensync1; if
it doesn't find that, it will look for opensync.
The primary drawback of using pkg-config is that most projects that
rely on it do not actually check if the data provided by the .pc
file is reliable, so configure may succeed but a subsequent build
will fail. It is always possible for a user to set PKG_CONFIG=true
when running configure and completely eliminate all of the data
provided by any associated .pc files, setting LIBS, CFLAGS, etc by
hand the 'old-fashioned' way.
The primary drawback of not using pkg-config is that the user
has to set LIBS, CFLAGS, etc. the old-fashioned way. In practice,
this is pretty trivial, and all pkg-config has done is move the
data from a single CONFIG_SITE file to separately maintained
.pc files for each package.
If you do use PKG_MODULE_CHECK, follow it up with a call to
AC_CHECK_LIB or AC_SEARCH_LIBS to validate the data in whatever
.pc file was located by PKG_CHECK_MODULES
I'm assuming that the place at which this occurs inside your configure.ac is inside a PKG_CHECK_MODULES call.
Looking at the libopensync sources, it seems that libopensync1 is the newer name, and libopensync is the old name. So, we'll use pkg-config macros to look for the newer name unless it doesn't exist.
Put this in your configure.ac:
# Check if libopensync1 is known to pkg-config, and if not, look for libopensync instead
PKG_CHECK_EXISTS([libopensync1], [OPENSYNC=libopensync1], [OPENSYNC=libopensync])
Then later in your PKG_CHECK_MODULES call, replace libopensync1 with $OPENSYNC.