Windows 10 Gets a Package Manager For the Command Line

aojensen writes: ExtremeTech reports that the most recent build of Windows 10 Technical Preview shows that Windows is finally getting a package manager. The package manager is built for the PowerShell command line based on OneGet. OneGet is a command line utility for PowerShell very similar to classic Linux utilities such as apt-get and yum, which enable administrators and power users comfortable with the command line to install software packages without the need for a graphical installer. ExtremeTech emphasizes that "you can open up PowerShell and use OneGet to install thousands of applications with commands such as Find-Package VLC and Install-Package Firefox." It's a missing feature Linux advocates have long used to argue against Windows in terms of automation and scale. The package manage is open to any software repository and is based on the Chocolatey format for defining package repositories."

Comments

We can do that thing you like

[Anonymous Coward]

Everything except open-sourcing the code that is.

Re:We can do that thing you like

[khasim]

Installing via the command line is nice. But it isn't what I want.

I want a package system that locks the files down so that package X owns abc.dll and will not allow package Y to overwrite it.

And searchable. What package installed abc.dll? What packages depend upon that package?

Re:We can do that thing you like

[His name cannot be s]

Actually, to be perfectly clear, OneGet isn't really a package manager.

It's a package-manager-manager -- It's a unified way of installing packages of software regardless of the how-it's-implemented-on-the-back-end.

The first real package provider plugin is a Chocolatey one. Why re-invent the wheel when the wheel already works?

The purpose here is to leverage all these different sources of software using a common set of commands and APIs.

Anything that can be represented as a 'source' of software can be plugged in on the back end. I'm aiming for plugins for NPM, Ruby Gems, Python, on top of the expected MSI, Chocolatey, NuGet, etc...

Plugins can be written by anyone, and I'm going to great lengths to make it as simple as possible -- it's about ~15 or so functions to implement and we can plug in virtually any package format or service into OneGet.

Re:We can do that thing you like

[Anonymous Coward]

What makes you think they won't open it up?

MS has done a pretty abrupt about-face over the past couple of years. MVC/WebAPI, Roslyn, EntLib, EF, WinJS, etc. are open source. Much of the .NET stack is open source. You can easily stand up an entirely open system on Azure (Mongo/Hadoop/Node, many other options).

They've even got internal movements going to open up some of their popular but unsupported software, like LiveWriter.

Re:We can do that thing you like

[CastrTroy]

I never really understood DLL Hell. In Windows I've had very few instances of any that I can think of where 2 programs had conflicting versions of the same DLL. In Linux, I've had all kinds of dependency hell. In the early days, before there was automatic dependency resolution, you had to track down dependencies by yourself, often leading to circular loops or being unable to find a certain version of a library that was needed to install something. Now that dependencies are automatically resolved, you can still run into problems where one package requires the old version, and a different package requires a new one, and you can't install both versions at the same time. The problem usually crops up as soon as you have to install something that isn't in the main repository. If something isn't in the main repository, and isn't statically linked, the odds of a successful install plummet quite low.

Re:We can do that thing you like

[benjymouse]

https://en.wikipedia.org/wiki/...

Rather than leaving the dependency resolving responsibility to package maintainers, the Windows OS contains a brokering mechanism that will load the correct version of an assembly - even if multiple versions of the same assembly exists in the global assembly.

Linux package managers have dual responsibilities: Provide available software (with update mechanism) and ensure dependency hell does not rear its ugly head. Linux dependency hell is very real, once you step outside the repositories.

Windows has binary compatibility with software that was developed for Windows 95 / Windows NT 3.1 (where Win32 debuted). The dependency problem (called DLL hell in Windows) was solved with the SxS and the broader use of the Windows Installer package manager, which integrated with SxS.

Re:We can do that thing you like

[benjymouse]

The installer should put abc.dll in the same directory as the .exe file instead of a shared location.

No!

If the DLL is indeed candidate for being shared (e.g. part of a shared product) it should put the assembly/DLL in the Global Assembly Cache (GAC). This is a side-by-side store where the same assembly/DLL can exist in multiple versions.

If security vulnerabilities are found and a patch is released, only the version in the GAC needs to be updated, often by registering a new version with a manifest/redirection that will ensure that anyone requesting the old (vulnerable) version will be treated to the new (fixed) version.

Windows Installer does this. And supports patching.

Re:We can do that thing you like

[VGPowerlord]

DLL hell was *very* real in the Windows 9x days. Side-by-side assemblies was introduced with Windows 98SE (IIRC) - but really only became de rigueur with Windows XP. During the 9x days, software developers took advantage of the fact that nothing prevented them from writing files to the system directories. When they encountered a problem where they needed a DLL - they simply installed it in the system directory - often overwriting whatever was there before. Obviously this caused all sorts of problems where only the latest installed product had a robust state.

To add to this, Microsoft shipped a faulty copy of mfc42.dll with Visual C++ 6. It removed a bunch of functions.

Now, keep in mind that mfc42.dll was used by any MFC applications compiled by Visual C++ 4.2-6.x... including Netscape, Microsoft Publisher, and a number of other programs.

Oh, did I mention that MFC was the recommended way of writing Windows programs back then?

Incidentally, Microsoft started including the VC++ version number in its DLL names again after this thanks to that screwup... which they had done before (vc++ 4.1 had mfc41.dll, etc...)

Oh boy, another infection vector

[Russ1642]

This is just an easy way to install software without much popping up on the screen to alert the users. I wonder how long it'll be before reports of infections using this installation method. What we really want is someone typing Install-Package Chrom and getting infected because of a typo.

Re: Oh boy, another infection vector

[Anonymous Coward]

It's not a problem on linux because the community manages the software repository.

And as the half dozen or so people in the community all know each other, it's not likely they're going to shit on their friends.

/jk

Re: Oh boy, another infection vector

[MMC Monster]

The problem with user controlled is that the user will add a repository and forget about it.

It happens on the Linux side as well. It just doesn't make news because there it's mostly white hats and not black hats.

Imagine this scenario: A website says it is packaging Windows10 versions of VLC with special added codecs to play stuff it otherwise doesn't play. People then add the repository and all is well. A year later, the repo gets hijacked by a virus and adds a version of GIMP v999 with the virus. Since it's a newer version of GIMP than what everyone has, they download it automatically and are infected en mass. People aren't looking for it since they already vetted the repo.

It happened with Ubuntu a while back, where some guy noticed his private repo was getting thousands of hits. So he put a new version of the default desktop background picture in it telling people to get off his repo.

Yay! Another Unix!

[jfbilodeau]

Now that Windows is kinda-sorta-Unix-like, should it be on DistroWatch.com? </sarcasm>

Respect

[nine-times]

I really respect this move from Microsoft. It's something they should have done a while ago, but better late than never. It has the potential to make administration much easier. They should also maintain their own repo of patches as an optional replacement for Windows Update.

Re:Respect

[His name cannot be s]

[FYI -- I'm @FearTheCowboy everywhere else, my /. id is so old that my name got trimmed from "His Name Cannot Be Spoken" 15ish years ago when they did a database adjustment... ]

I have had thoughts on how to do this; I suspect that while we may not set up a repo to do that, I may hack out the instructions on how that could be done easily if one wanted to maintain their own.

It really boils down to how much time I can throw at that.

Of course, we also want it to plug into WU and WSUS, but that'll be a bit more down the road.

On other words ...

[lennier1]

sudo apt-get install malware

Is this the year of the Windows Desktop?

[rapiddescent]

we've been saying it for years and years but now that Microosft Windows has a package manager, is 2014 finally the year of the Windows desktop?