Microsoft have any plans to provide a package repository?

[aetos382]

Currently, Microsoft provides a manifest repository, and the installer package must be retrieved from another site. Are there any plans for Microsoft to provide a repository to host the installer packages?

winget plans to support package dependencies. For example, if version 1.0 of package X is referenced by another package Y, version 1.0 should not be deleted even if version 2.0 of X is released. For this reason, nuget.org does not support deleting a version of a package once published.

To ensure that past versions of packages remain available, there needs to be a centralized package repository where both packages of X and Y can be managed in the same place under a unified package management policy, and Microsoft should provide such one.

[Croydon]

This might cause legal problems for the cases where it isn't allowed to distribute installers further or those would need to be excluded

[ghost]

@aetos382 To expand on and confirm what @Croydon said, here's an excerpt from Chocolatey's FAQ where they talk about this issue:

Are you redistributing software?

No. Packages on Chocolatey's community repository (https://chocolatey.org/packages) are publicly available and as such they are subject to software distribution rights. With those packages the following applies:

Chocolatey does the same thing that you would do based on the package instructions. This usually means going out and downloading an installer from the official distribution point and then silently installing it on your machine. With most packages this means Chocolatey is not redistributing software because they are going to the same distribution point that you yourself would go get the software if you were performing this process manually.

To put it another way, Microsoft would be quite upset if the Office 365 packages on the community repository actually contained the Office 365 binaries.

Most proprietary programs on Windows are licensed under terms that prohibit their redistribution by unauthorized third parties. What this means is that under current copyright law, neither Microsoft nor anyone else can legally create a comprehensive public package repository for Windows.

[denelon]

As others have stated, there are independent software vendors who prohibited third-party distribution.

[aetos382]

I don't think that the package repository provided by Microsoft should be the only repository for winget. So, having an installer that prohibits redistribution is no reason for Microsoft not to have such a repository.

Many installers distributed in the form of EXE or MSI are also responsible for resolving the dependencies that are necessary for the software to work. Such software does not require the dependency resolution capabilities provided by winget.

But, for winget to support package dependencies, it needs a repository with a package retention policy. If a package that is required by a lot of software can be removed without a retention policy, or replaced with a different one with the same identity, it will cause a lot of confusion. Such problems have occurred in the past with repositories like npm.

I believe Microsoft already knows about the need for repositories with retention policies, as they are a company with experience running repositories like nuget.org and npmjs.com.

[majkinetor]

Most proprietary programs on Windows are licensed under terms that prohibit their redistribution by unauthorized third parties. What this means is that under current copyright law, neither Microsoft nor anyone else can legally create a comprehensive public package repository for Windows.

Throw out the baby with the water ?

For intented population that winget is built for, majority of tools allow redistribution because they either have permissive FOSS license (GNU, MIT etc.) or it is expliciatelly stated in custom license or it is given by the vendor itself on request. That is what we do on chocolatey core team to package ~300 mainstream tools with millions of downloads.

So while most propriatery programs are licensed that way, there are bunch of FOSS tools that are not. We need both mechanisms in place - download automation AND embedding entire stuff in a package (readmes, executables, icons, licenses etc.).

The trend of FOSS on Windows is only accelerating so this will even get better, rather then worst in the future.

Here's an excerpt from Chocolatey's FAQ where they talk about this issue

The quote that @whalehub provided above was mostly in effect prior to intorudction of embedded packages which is a time when Chocolatey sucked - installing a package was akin to tossing a coin and hopping for the best because of multiple reasons. The only solution to that problem was to use enterprise version which caches downloads so when the vendor removes them, they still work on Chocolatey, however, it was still far from good because you couldn't do some other things, like caching them locally and you still needed to be constantnly online and depend on 3rd party infrastructure (which is not great either). Embedded packages are recommended now.

I personaly wouldn't even consider using a package manager that doesn't have this, nor would I recommend it to anybody.

[denelon]

I'm working on the specification for dependencies #163. I'm converting this Issue to a Discussion.