I am using Chocolatey to make installers for a bunch of different tools, but the versions I need for some of these tools are considered outdated and are not available as packages on the Chocolatey package repository. What should I do?
If you are part of an organization, I (and Chocolatey.org) recommend setting up your own Chocolatey feed and building your own packages for internal use. This way, you control the package versions and their sources. Another benefit is that you can host the source internally or embed any installation files in the installer without worrying about distribution rights (as long as the feed is only available internally).
Unfortunately, you can't squeeze blood from a stone. Many packages in the public Chocolatey feed are "unofficial" from the software's point of view (as in, not maintained by the vendor) and as such it's tough to rely on the public feed. If you can't get the package maintainer to update the package, and you don't want to maintain your own feed, then as long as you can commit to keeping the package up to date for the community then consider creating your own community package to maintain.
Related
I am looking to replace CoApp because CoApp is no longer supported. I have explored few alternatives but they seems to be more aimed at installing and uninstalling software than creating and consuming packages in a build environment.
So need any suggestions on alternative of CoApp.
My company sells a software product, which intended to be consumed by (large) enterprise customers. These customers usually using RedHat operating system (RHEL 7\8).
These customers usually have a strict security policies, such as a firewall rules preventing them to download anything from "unconfirmed" sources. Making them to change anything in these rules is a real pain in the *** (anyone who ever worked with enterprises knows what I'm talking about).
So my goal is somehow to distribute my software in some well known and widely accepted way which will cause a minimal possible traction with IT / INFOSEC departments of customer companies.
I was thinking that a first step would be to package my software as a RPM package. However, it is not clear to me where to (and how) to upload that package, so it will became "natively" available for enterprise RedHat users.
What would be the "native" way to distribute software to RedHat enterprise customers?
You can look into one of these:
create a YUM/DNF repo (possibly a private repo) that they can connect to and ship your rpms through that repo (this is the most common way of shipping software to users)
give them instructions to set up their own local YUM/DNF repo and they can add whatever RPMs (that you give them) to the repo
create signed RPMs and ship them to the customers directly. They will have to confirm that your gpg key is trusted and they can verify that the RPM is unmodified. Here they will be using the rpm command directly to install the packages, not doing it through yum
just give them plain RPMs and the md5sum of those packages so they can verify manually that the RPM you've given them has not been tampered with
Installing RPMs from a repo takes care of install/upgrade dependencies automatically, but if you ship the "raw" RPM the customer would have to install dependencies manually.
I can fine a whole bunch of information on how to install packages using Package Management (nee PowerShellGet (nee OneGet)), but I can find nearly zero information on creating those packages.
I did find this which describes how to use the Publish-Module cmdlet to publish a PowerShell module, but I cannot find any information on how to create any other sorts of packages.
Specifically, I would like to create two types: from an .MSI, and from an .EXE. The .EXE I only need installed somewhere on the system, and I need the ability to update the PATH environment variable to allow it to be run by users. For the .MSI, I would ideally like it to be installed (using msiexec), but if that's not possible, I can use other means.
The only remotely-related information I can find is from Chocolatey, which is a system that predates Package Management but that Package Management works with (maybe? sorta? not really clear?). Chocolatey can create packages, but is that really the only way to create packages for Package Management?
Where can I find information on how to accomplish these packaging tasks?
To quote Microsoft:
PackageManagement is essentially a Package Management Aggregator. It creates a unified and consistent PowerShell interface for users and provides a plug-in model at the back end that different installer technologies or package managers can plug-in as providers, using PackageManagement APIs. Each provider further manages one or multiple package sources (repositories) where software packages are stored.
This means there isn't a single way of creating packages, it will depend which Package Management Provider and/or Package Source you are using.
NuGet is widely documented, and so is Chocolatey (which has a plugin available for package management)
If you're looking to install your own private software, as opposed to commercially available software (where you're best off just using one of the existing repositories), you will need to create your own feed/repo. Again this will depend which options you're using. For example, the NuGet documentation on this is readily available.
We use various packages of NuGet in our company for productive applications. But we do not know how long a particular version of a package is available.
We do not want to include the packages in the source control system.
To be precise. If our source code is older than 10 years, is then a package in a particular version still available?
With NuGet.org you can delist a NuGet package but not permanently delete it. Delisting removes it from the search results but it is still available for NuGet package restore.
That being said the NuGet team can permanently delete NuGet packages in exceptional circumstances. This has happened at least once, as far as I am aware, when Oracle asked the NuGet team to remove some NuGet packages that were using their software or could be mistaken as being supported by Oracle.
So in practice the NuGet packages will be available as long as NuGet.org is still around. However it is hard to predict what will be happening in 10 years time.
No one knows exactly how long a package is available. When a new version comes out, sometimes the old version is still available and sometimes it's not. AFAIK, they don't have a release schedule, so no one is ever sure when a new version is available until very close to the release date.
It was there yesterday and now its page is completely gone. A bunch of my builds straight up started failing, I didnt think that nuget removed packages.
Is there any way I can find out why its just completely gone?
https://www.nuget.org/packages/odp.net.managed/
Indeed. Somehow Oracle removed their nuget package odp.net.managed causing a lot of headaches among developers relying on it.
However, you can use the package Oracle.ManagedDataAccess which offers the same functionality.
In normal situations, permanently removing a nuget package from nuget.org is not supported (source). I guess Oracle explictly forced the nuget.org team to remove it for reasons unknown (maybe licensing?).
I suspect that is one of the NuGet packages that Oracle asked Microsoft to remove from nuget.org.
Oracle identified some NuGet packages that were using their software or made it look as though they were from Oracle and asked Microsoft to remove them.
There is a Package Content and Removals blog post about this which includes information about what NuGet packages should be used instead:
If you are looking for the official Oracle software, they ask that you please download the Oracle.ManagedDataAccess package or the Oracle.ManagedDataAccess.EntityFramework package to work with the Oracle database using Entity Framework.