On my linux (Ubuntu 11.04) development machine. I often need to install libraries from source. This always causes problems for me because the package manager doesn't consider packages installed from source when it checks dependencies. This makes the package manager worthless to me since once I install one set of libs from source (especially if they are vital to the gnome environment i.e. gstreamer), I can never use it again without screwing up my entire distro with mixed dependencies. It seems to me that it would be relatively simple to check the dependencies with pkg-config without having to worry with the deb database. I don't mind writing a little code here. Does anyone have any ideas?
Alternatively, you should look into the equivs package, which is made exactly for the purpose of creating empty .debs that will make apt/dpkg think a certain package is installed when it isn't.
Grab the source package from Debian unstable and build a .deb from that using the developer tools. If you need an even newer upstream version, you can apply the .diff.gz part of the Debian source to an upstream tarball and get a build infrastructure that has good chances of working. If if doesn't, I'm sure the package maintainer would appreciate patches to make it work with the new upstream version.
Another option would be checkinstall. It creates a .deb package containing dependency information, but also you will be able to uninstall it via package management.
Related
I am following this tutoriel to use C library in Kotlin (Android Studio) https://jonnyzzz.com/blog/2018/05/28/minimalistic-kn/ But I can’t find the how to install/download the cinterop tool both in Windows and Ubuntu I have the error “cinterop: command not found” ! Does anybody please knows how to install cinterop ? Thank you in advance
This tool is a part of the kotlin-native distribution, and it does not make any sense to use it without the Kotlin/Native compiler. So, in fact, you would like to get all the distribution here, and install it correctly.There are three main approaches to the Kotlin/Native installation. All of them are described in the documentation.
Installing it with the IntelliJ IDEA. You should just get an IDE and let it install everything on its own. It will download all tools and put them to the following location: ~/.konan/kotlin-native-prebuilt-<osName>-<kotlinVersion>/bin/. Then you will be able to add this folder to your PATH and call the tool from CLI.
Installing using the Gradle build system. Quite similar, but this one will require manual installation of the Gradle. The first run will also download all tools and pack them to the same location as in the IDE case.
Installing the CLI tool. This looks like the most appropriate way to follow the tutorial, but won't help a lot when you start working on more sophisticated projects. In general, you should just download the latest version of the Kotlin/Native, unpack it to some folder and add this folder to your PATH.
We've been a Windows shop, mainly relying on Visual Studio as our IDE and build tool. We've begun to explore using Angular and node, and angular-cli.
We have a project that depends upon "angular-cli": "1.0.0-beta.10". I was trying to get this to build on a new machine.
I installed nodejs, then did a global install of angular-cli using npm:
npm install -g angular-cli
Then I tried to do a build:
ng build
I got an error:
It seems like you're using a project generated using an old version of the Angular CLI.
The latest CLI now uses webpack and has a lot of improvements including a simpler
workflow, a faster build, and smaller bundles.
To get more info, including a step-by-step guide to upgrade the CLI, follow this link:
https://github.com/angular/angular-cli/wiki/Upgrading-from-Beta.10-to-Beta.14
What I did to get things working was to uninstall angular-cli, and then install version beta.10
npm uninstall -g angular-cli
npm install -g angular-cli#1.0.0-beta.10
After that, things work just fine.
Unfortunately, that's not a solution.
We will, eventually, have multiple projects using node packages, we need them to be able to run simultaneously, without having to uninstall and reinstall global packages.
And we need to be able to run builds automatically on our build machines, without having to RDP into the build machines to mess about with which node packages are installed.
That is, if I have three projects that use angular-cli#1.0.0-beta.10, I expect all three to work on any of the developers machines, and that the build machines will be able to check out any of the three projects and successfully build them.
And if I update one to use beta-12, and another to use beta-14, I expect to be able to commit them to version control, and for the build machine to be able to check out any of three and still be able to build them, regardless of which version they use.
I thought the whole idea of tracking local dependencies in package.json, and storing local copies in node_modules was to avoid dependencies on globally installed packages.
How do people usually manage this issue?
Is there a way I can configure angular-cli so it doesn't depend upon a global install?
Are there other packages with which I'm likely to encounter similar problems? Is there an approach that will work for any of them?
The Angular-CLI can be run with, and the global ng command uses, a locally installed version for each project. This local version can be accessed using the command ./node_modules/.bin/ng
I recommend uninstalling the global CLI you have and taking the time to modify your package.json scripts to reference the local CLI installation rather than the global ng. This is my method to handle varied CLIs on my Jenkins server.
On that note, I do highly suggest following the instructions to move from Beta.10 to Beta.14 (https://github.com/angular/angular-cli/wiki/Upgrading-from-Beta.10-to-Beta.14) if you can stomach the change to WebPack. Any projects utilizing CLI Beta.14 or higher can be upgraded to the latest beta simply by uninstalling the CLI, reinstalling it, and then running ng init (Diff [d] any files you've modified!) to update the boilerplate.
Copy & Paste the typescript components html's and css/scss files to a new build, it's not even worth it to mess with the core build of those stuff.
Bear in mind that you might see imports being grayed and the same very imports to be needed to add in app.module.ts as its a core file nowadays to every single project of ours.
On reviewing the chocolatey packages available, I came across a few that have two (or sometimes more) packages apparently for the same product. At first glance is not possible to tell the difference.
For example, there is the AutohotKey package, and then there is also an Autohotkey.install package.
What is the difference between both types of packages?
Have a look at the FAQ in the Chocolatey wiki here:
https://docs.chocolatey.org/en-us/faqs#what-is-the-difference-between-packages-no-suffix-as-compared-to.install.portable
Quoting from that article:
tl;dr: Nearly 100% of the time, the package with no suffix (autohotkey in this example) is going to ensure the *.install. The package without the suffix is for both discoverability and for other packages to take a dependency on.
Chocolatey has the concept of virtual packages (coming) and meta packages. Virtual packages are packages that represent other packages when used as a dependency. Metapackages are packages that only exist to provide a grouping of dependencies.
A package with no suffix that is surrounded by packages with suffixes is to provide a virtual package. So in the case of git, git.install, and git.commandline (deprecated for .portable) – git is that virtual package (currently it is really just a metapackage until the virtual packages feature is complete). That means that other packages could depend on it and you could have either git.install or git.portable installed and you would meet the dependency of having git installed. That keeps Chocolatey from trying to install something that already meets the dependency requirement for a package.
Talking specifically about the *.install package suffix – those are for the packages that have a native installer that they have bundled or they download and run.
NOTE: the suffix *.app has been used previously to mean the same as *.install. But the *.app suffix is now deprecated and should not be used for new packages.
The *.portable packages are the packages that will usually result in an executable on your path somewhere but do not get installed onto the system (Add/Remove Programs). Previously the suffixes *.tool and *.commandline have been used to refer to the same type of packages.
NOTE: now *.tool and *.commandline are deprecated and should not be used for new packages.
Want more information? See http://ferventcoder.com/archive/2012/02/25/chocolatey---guidance-on-packaging-apps-with-both-an-install.aspx
Setting up a new environment with choco recently and became curious about this too. Chocolatey seemingly created a dedicated documentation site and moved the FAQs there, updating link to:
https://docs.chocolatey.org/en-us/faqs#what-is-the-difference-between-packages-no-suffix-as-compared-to.install.portable
I'd love to use Pandoc in a utility I'm writing (C# console app) and I found this bindings project on GitHub, libpandoc and by extension, it's .NET bindings project, libpandoc-dotnet.
I wish the author had included the built DLL but I suppose he wanted to leave it open to future Pandoc versions.
I have no Haskell experience whatsoever, I just want the .NET bindings in the end. I'm trying to install the dependencies via cabal but I don't understand the error messages and a cursory search leads me to believe installing base is a no-no, so I'm not sure what to do.
C:\Development\Contrib\libpandoc>cabal install base-4.1.0.0
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: base (user goal)
rejecting: base-3.0.3.2, 3.0.3.1, 4.6.0.1, 4.6.0.0, 4.5.1.0/installed-7c8...,
4.5.1.0, 4.5.0.0, 4.4.1.0, 4.4.0.0, 4.3.1.0, 4.3.0.0, 4.2.0.2, 4.2.0.1,
4.2.0.0 (global constraint requires ==4.1.0.0)
rejecting: base-4.1.0.0 (only already installed instances can be used)
rejecting: base-4.0.0.0 (global constraint requires ==4.1.0.0)
If a kind soul could even build the damn thing (fork it? upload it somewhere?) I'd love you forever. Alternatively, show me how to build it properly and I can handle it from there I think. Though now that I think about it, not sure I have a C compiler installed.
Update:
OK. So it all comes down to the fact that libpandoc is 3 years old and its dependencies are out of date. I had no luck trying to get all the old Haskell tools to install and work, I probably had no idea what I was doing. I got as far as installing some dependencies but some dependencies weren't versioned so I had to track each version specifically and I eventually gave up.
I then just updated the dependency versions for libpandoc itself and now I've got all the dependencies built and linked.
The only remaining issue is that libpandoc needs to be updated to work against the latest Pandoc release (1.10).
Is there an obvious way to get Clutter Toolkit up and running in Ubuntu. It seems like there is a huge list of dependencies as I try compiling it.
The current dependency which I am unable to resolve is "cogl-pango-1.0".
Any suggestions on getting up a running with Clutter, for development?
11.04 already ships with clutter 1.6.14: http://packages.ubuntu.com/natty/libclutter-1.0-0
see also: http://packages.ubuntu.com/source/natty/clutter-1.0 for the development and documentation packages.
the dependencies list is not "huge": most of the requirements are already available in 11.04 as -devel or -dev.
if you want to build from sources, I can recommend using jhbuild: the necessary steps are provided here: http://wiki.clutter-project.org/wiki/BuildingClutter#Building_from_Git