Is openssl/1.1.1d#_/_ the same as openssl/1.1.1d? I'm confused by those different suffixes like _/_, conan/stable, bincrafters/stable, are they eventually replaced by openssl/1.1.1d?
Yes. Since Conan 1.18, the namespace (user/channel) has become optional. Thus, the correct reference for the official OpenSSL package now is openssl/<version> e.g.
conan install -r conan-center openssl/1.1.1d#
The # is required to identify that you are using using name/version format. It's a compatibility feature.
However, the package folder path uses same format yet, e.g.
/home/user/.conan/data/OpenSSL/1.0.2o/conan/stable/package/6af9cc7cb931c5ad94
Now, without the namespace, both user and channel has been replaced by the placeholder _/_:
/home/user/.conan/data/openssl/1.0.2o/_/_/package/6af9cc7cb931c5ad94
Note that you don't need to touch this, you only need to invoke the reference by putting a # as terminator.
Related
I am making a package for cmake/3.10.2 and I want that whenever I do conan install . it should display devenv instead of conanenv. I don't want to manually change activate.sh file. Is there any way to do it from conan recipe. I am using virtualenv as generator.
Unfortunately not, the name is hard-coded, you can check it on the code.
However, you could open an issue requesting for such feature.
Regards!
I am trying to use the docker API for golang that is available from github.com/docker/docker/client. So far I am able to start the containers on the port that is predefined during image built. I am trying to map the port during runtime using the API; something equivalent to
docker run -p 8083:8082 -d myImage:1.0.0
I tried to do something like the following for mapping the ports:
host_config := &container.HostConfig{
PortBindings: nat.PortMap{
"8082/tcp": []nat.PortBinding{
{
HostIP: "0.0.0.0",
HostPort: "8983",
},
},
},
}
The problem here is that the variable "nat" lives inside the vendor folder of the API. I couldn't import something directly from the go vendor folder. Someone on the stackoverflow suggested to copy the go-connection folder into the github folder and remove the nested vendor directory. I did as suggested and created a path as follows:
"github.com/docker/go-connections/nat"
now I get the following error during compile time:
src\main\createcontainer1.go:53: cannot use "github.com/docker/go-connections/nat".PortSet literal (type "github.com/docker/go-connections/nat".PortSet) as type "github.com/docker/docker/vendor/github.com/docker/go-connections/nat".PortSet in field value
src\main\createcontainer1.go:65: cannot use "github.com/docker/go-connections/nat".PortMap literal (type "github.com/docker/go-connections/nat".PortMap) as type "github.com/docker/docker/vendor/github.com/docker/go-connections/nat".PortMap in field value
Have anyone faced this issue and overcome it? I am using the Go ver 1.8.
So you need to do more than just copy it, you need to move it. The same package located in two different locations are different packages to the go tool (because it can't guarantee they are identical, so it uses fully-qualified import paths).
If a package you're using has a vendor directory, and you need to use the packages in it, you have two options:
Move everything out of the vendor directory in that package into your $GOPATH/src
Vendor the package itself, and then move everything from the package's vendor directory into your project's vendor directory (<project root>/vendor). This is known as "flattening" your vendored dependencies, and most Go vendoring utilities (ex. Govendor or Godep) can do this, either automatically or with a flag. You can also do it manually, though.
The latter is generally the recommended strategy. The important key, though, is that the package itself cannot have a version of that library in its own vendor directory, as Go tool automatically uses the deepest vendored version of a package that it can access.
For creating and maintaining Perl 5 modules, I use Dist::Zilla. One of my favorite features is being able to install local modules.
However, with Perl 6, I'm not sure how to install local modules. Sure, I can use use lib:
use lib 'relative/path';
use My::Awesome::Module;
But, I'd really like to be able to install My::Awesome::Module, so that all I had to do was use it:
use My::Awesome::Module;
One way to accomplish this, would be setting PERL6LIB, but that still isn't "installing" a module like zef install ./My-Awesome-Module.
Update: Looks like I need to craft an appropriate META6.json file.
To understand how to setup a module to be understood by toolchain utilities, see Preparing the module. Typically this means adding a META6.json file that describes the distribution, including quasi-manifest elements such as which files you really meant to include/provide. Once the META6.json is created the module is ready to be installed:
zef install ./My-Awesome-Module
which (assuming no uninstalled dependencies) is essentially:
my $install-to-repo = CompUnit::RepositoryRegistry.repository-for-name("site");
my $preinstall-dist = Distribution::Path.new("./My-Awesome-Module");
$install-to-repo.install($preinstall-dist);
Starting with rakudo 2019.01 you can, assuming no uninstalled dependencies, install a local distribution without a META6.json -- but this is purely developmental nicety that won't work on complex setups that do not have e.g. namespacing and file structures that can be inferred.
my $read-from-repo = CompUnit::Repository::FileSystem.new(prefix => "./My-Awesome-Module/lib");
my $install-to-repo = CompUnit::RepositoryRegistry.repository-for-name("site");
my $some-module-name = "My::Awesome::Module"; # needed to get at the Distribution object in the next step
my $preinstall-dist = $read-from-repo.candidates($some-module-name).head;
$install-to-repo.install($preinstall-dist);
I'm writing a bin that may help you: http://github.com/FCO/6pm
I am developing a library which uses CMake to control it. It would be good to provide a "FindXXX.cmake" which locates the library and header files. This file would enable the users to use the command "find_package(XXX)" to find my library.
However, I don't know how to install my lib's "FindXXX.cmake" to an correct location. I failed to find a CMake's build-in mechanism to install a "FindXXX.cmake". In addition, CMake's variable "CMAKE_MODULE_PATH" is a list of directories, so I cannot install according to that vairable because I cannot decide which specific directory to use.
If the copy of CMake is installed to a standard location(i.e. use no prefix etc) then this can be done by placing the file in /usr/share/cmake/Modules/ directory.
If you are going to supply a bundle probably you can add some commands to check if the cmake is available. if yes you can check for cmake --system-information|grep _INCLUDED_SYSTEM_INFO_FILE value from that to get modules directory.
Otherwise there's no way you can do that.
A workaround can be done i.e. if there is a binary in your bundle then you can add a command line option for placing this file.
I would like to use a rpm to build subpackages for different environments (live,testing,developer) but for the same files, so having a package called name-config-live, one called name-config-testing and one called name-config-developer and in them to have the same paths but each with the configs corresponding to the environment it's named after.
as an example
let's say on all environments I have a file called /etc/name.conf and on testing I want it to contain "1", on development "2" and on live "3". Is it possible to do this in the same spec since the subpackage generation only happens last not in the order I enter it. ( and hopefully not with %post -n )
I tried using BuildRoot but it seems that's a global attribute
I don't think there's a native way; I would do a %post like you had noted.
However, I would do this (similar to something I do with an internal-only package I develop for work):
Three separate files /etc/name.conf-developer, /etc/name.conf-live, etc.
Have all three packages provide a virtual package, e.g. name-config
Have main package require name-config
This will make rpm, yum, or whatever require at least one be installed in the same transaction
Have all three packages conflict with each other
Have each config package's %post (and possibly %verify) symlink /etc/name.conf to the proper config
This also helps show the user what is happening
Cons:
It's a little hackish
rpm --whatprovides /etc/name.conf will say it is not owned by any package