(git) Major problem with 2.11.0 (unable to push to UNC paths)

[laurinkeithdavis]

We are having to rollback all machines to Choco Git 2.10.2 due to git-for-windows/git#979. 90% of the repos we use are over UNC paths. I'm not sure how this one should be handled, but due to the severity of the problem for some users, I figured I should open a PR here as well for now and see if we options other than this:

cup git --version 2.10.2 --allowdowngrade
choco pin add -n=git

Then of course, we will have to remove the pin when this is fixed in Git itself.

[ferventcoder]

Unfortunately problems in software versions typically do not give a right to withhold the new version. The vendor released a new version of the software, so the package should reflect that.

[ferventcoder]

Thanks for letting me know about the issue (and anyone else that is watching this thread). It's good to have an awareness of those issues.

[ferventcoder]

Unfortunately problems in software versions typically do not give a right to withhold the new version. The vendor released a new version of the software, so the package should reflect that.

This policy is meant to reduce ambiguity and abuse. Leaving it up to the maintainers to decide to withhold a version the software vendor released because it has some bug they don't agree with or breaks them in some way is not really in their purview. The right of release exists (and must exist) only with the software vendor.

HTH

[laurinkeithdavis]

I understand why, but when we are now trying to manage software on 20 machines using Choco, that means we have one of 2 options when this occurs (the above), or tell everyone to not run cup all until this is fixed - the first is time consuming and the second is bound to not be followed (not to mention the additional fallout).

This issue is another reason into the bucket of why we need some way to "globally" manage the behavior of Choco - some way to globally pin a version so that all user are always on the same version.

Like the behavior of Composer - this model is a dream. Update modify composer.json, composer update to update composer.lock. Commit and distribute all through Git. All users run composer install, now all users are on the same version. Even can automate that process using CI (we use Jenkins), so that test and prod are also all on the same version.

I realize that you don't want to be in the business of moderation, except for package installation and security, but right now, there is a major piece missing. I'd contribute if I knew what direction to go in and how to help.

[ferventcoder]

So the major piece that is missing to me is running your own internal server and using the Business Edition to internalize the packages you desire. Then when you want to pin to a particular version, you just don't have it available in your internal source and things work automatically. That is your global and supported package set. The use of Chocolatey's community repository for organizational use is limited at best but not really supported. See https://chocolatey.org/docs/community-packages-disclaimer

It's also much more intentional on when you take on upgrades, so one thing that is being worked on is seeing newer versions and allowing choco to internalize newer versions automatically.

One could always install from a packages.config, and we could work on upgrades with packages.config as a feature there since it sounds like it is desired and similar to a workflow you just described.

[ferventcoder]

Minus the business edition, you can still do the internal packages and vetting and manually internalizing existing packages (however, much more manual work involved).

[laurinkeithdavis]

So the major piece that is missing to me is running your own internal server and using the Business Edition to internalize the packages you desire. Then when you want to pin to a particular version, you just don't have it available in your internal source and things work automatically. That is your global and supported package set. The use of Chocolatey's community repository for organizational use is limited at best but not really supported. See https://chocolatey.org/docs/community-packages-disclaimer

That's a whole lot of work when we want to maintain a configuration only and not the actual packages.

[ferventcoder]

That's a whole lot of work when we want to maintain a configuration only and not the actual packages.

Right, that's why I made the second suggestion:

One could always install from a packages.config, and we could work on upgrades with packages.config as a feature there since it sounds like it is desired and similar to a workflow you just described.

Also going back to your original thoughts:

Commit and distribute all through Git. All users run composer install, now all users are on the same version. Even can automate that process using CI (we use Jenkins), so that test and prod are also all on the same version.

So right now you could use a packages.config file - and commit and distribute it around locally through git. Then users would run choco install packages.config through that. However I think you will more likely want something that manages installs. upgrades, and uninstalls with a packages.config.

Add thoughts to this issue - chocolatey/choco#533

[gep13]

This package is now being maintained here:

https://github.com/chocolatey/chocolatey-coreteampackages

So going to close this out.