Multiple Package Manager

Multiple package manager

The short answer is, yes you can, but you really shouldn't.

Below is a list of things (in no particular order) to consider when cross-distribution installing:

Dependency hell

The primary reason things like yum/apt/yast exist in the first place is to avoid what is known as dependency hell. By using packages from other systems, you forfeit the work that has been put into the packages from installing cleanly.

The secondary package manager will want to satisfy its own dependencies, and install a bunch of things that are already installed. This means you have to install packages a piece at a time so that you don't overwrite already installed packages from your primary package manager, and have all kinds of problems.

Do they use the same package manager?

If they do, you may even be able to just install it outright, but you'll likely have dependancy issues or package conflicts. If they don't, you can extract the package with various tools and just lay down the binary files onto the file system (have a look at alien, or this post about extracting .rpm and .deb files).

This will get you the files on the system, but there is no guarantee it'll work out of the box. Some additional manual hunting may be (and usually is) required.

Are the versions of base packages such as glibc the same or very close?

If so, there is less chance of an issue. The further difference between the two distribution's base packages, the more likely you'll have missing shared libraries that aren't available in the distribution you're running on, because the version is different and the filename doesn't match what the binary is looking for.

Technically you could also extract the base dependencies from the other distribution and put them on the filesystem as well, but that will certainly cause you pain should you ever need to compile things from source. Imagine how confused gcc will be.

Does the package you're installing call for a specific kernel module?

The best way I can articulate this is a common problem I see these days with buying VMs from a web host; you get their own brand of xen or virtuozzo kernel, and iptables doesn't work outright because netfilter is in the kernel and the ABI has changed. It can be quite the headache to get it working again, and this issue isn't limited to iptables. My best advice here is pick the distribution that has the kernel you want in its own base repository.

Compiling from source

No doubt you'll have to do this should you get very deep into wanting packages from other systems. Since the various distros setup their build environments differently, you'll be spending half your time figuring out pathing and other configuration issues.

Upload a package to multiple package managers from a single repo

is it possible to upload this project to multiple package management systems like Homebrew and Conda from a single repo or will there be any conflicts.

Not sure about Conda, but for Homebrew, it is totally possible and there are some github actions can help with the release process:

dawidd6/action-homebrew-bump-formula
mislav/bump-homebrew-formula-action

Update multiple packages on Package Manager Console in Visual Studio

You can separate the update commands using ; so it looks like this:

Update-Package <Package1> -version <version1>; Update-Package <Package2> -version <version2>; Update-Package <Package3> -version <version3>

This way you can just run it and go grab a coffee while it's updating.

Install several packages in one call to underlying package manager with Chef?

This is not an option as it doesn't lend itself to clear convergent modelling in the way the package resource currently works. You could build a resource for yum_batch or similar, but I don't know of one off hand. A possible future extension would be something like chef-metal's machine_batch resource wrapper, but I'm not a big fan of that approach.

EDIT: This was added in Chef 12.1.0. You can now do package ['one', 'two'] in recipe code.

Using Multiple Front End Package Managers Simultaneously (Bower, NuGet)

We use NuGet and Bower both and it has worked well for us so far. We are slowly moving the front-end libraries to Bower. You will have to create a Nuget package to use it from Nuget to install.

Swift package manager. Error: Found multiple packages with the name...?

Remove Package.pins and rerun swift build. See which packages it is trying to fetch. Check .build/checkouts and .build/dependencies-state.json - which tags and which versions, respectively, of CommonLib, are written there.

Multiple Package Manager