Yeah, but it’s mid at best. Many apps open a GUI installer even with winget. Also updates for many apps don’t work (if the app doesn’t save its version properly in the registry).
A package typically includes the program and its data inside the package. It’s not just an install script. Imagine if Chrome’s MSI installer was simply a wrapper that also downloaded the browser. Imagine if there was a vulnerability with this, and it downloaded and installed something else. Since the package didn’t include the program files, it wouldn’t be able to tell if they were genuine. It only fetched the MSI, which was a download that initially passed the expected checksum (if it even does that).
Additionally, file lists help ensure that programs and packages don’t conflict with one another. What if you wanted Chromium and Chrome at the same time. Can you do that? Simply wrapping an MSI doesn’t guarantee that. Perhaps there are conditionals in an installer that includes a vendored library under some circumstances, which would make them conflict.
What about package removals? Some programs leave a bunch of junk behind in their uninstaller. Typically, since packages very often contain their own files, they simply delete their files when they’re being upgraded or removed. If a package manager puts full trust in an MSI to always be exactly correct, then it loses complete control over correctly managing file removals.
I could go on and on, with more examples, but “run this binary installer” is the Wild West of putting software on your system. This is mostly the status quo on Windows, but this is a very poor standard. Other operating systems have solved this problem with proper packaging for decades.
When building a package from sources, it makes sense to wrap installers, but then you produce a package that is typically distributed by a mirror. These packages would then by downloaded by you, and contain the source of truth that is trusted to be what it is and that it’ll do what it’s supposed to do without any doubts to consistency and security.
Either the community on GitHub, or someone inside Microsoft.
You can find their repository here (I think most people here are not interested in it tho lol)
I have packaged some software for winget back when I was still using Windows, and yes it runs msi ( or exe ) silently under the hood. Installation processes that are usually done on GUI are automated just like how Homebrew does.
winget install Google.Chrome
Windows has a package manager like a big boy OS these days
WinGet is an AppGet rip-off without even a mention of the original creator. I’m still salty about that.
Microsoft offers to buy out AppGet and had its developer join them, but then ghost him once they realized the dev is also Sonarr dev.
Sorry is AptGet something other than Debian’s “apt get”?
AppGet was a package manager for windows.
Thank you
Are you the original creator?
Nah just thought he was treated very poorly by Microsoft.
deleted by creator
I think it’s now pre-installed.
Thats nice!
deleted by creator
Yeah, but it’s mid at best. Many apps open a GUI installer even with winget. Also updates for many apps don’t work (if the app doesn’t save its version properly in the registry).
I mean its still Windows, they dont package anything thats the job of the apps.
Who packages chrome?
I wonder how its packaged too, is winget firing off an MSI in the background with a silent flag?
That’s exactly what it does.
Interesting. Not much of a package manager, then 🤔
It downloads a package, it installs a package and then offers to remove that package. How is it not a package manager?
A package typically includes the program and its data inside the package. It’s not just an install script. Imagine if Chrome’s MSI installer was simply a wrapper that also downloaded the browser. Imagine if there was a vulnerability with this, and it downloaded and installed something else. Since the package didn’t include the program files, it wouldn’t be able to tell if they were genuine. It only fetched the MSI, which was a download that initially passed the expected checksum (if it even does that).
Additionally, file lists help ensure that programs and packages don’t conflict with one another. What if you wanted Chromium and Chrome at the same time. Can you do that? Simply wrapping an MSI doesn’t guarantee that. Perhaps there are conditionals in an installer that includes a vendored library under some circumstances, which would make them conflict.
What about package removals? Some programs leave a bunch of junk behind in their uninstaller. Typically, since packages very often contain their own files, they simply delete their files when they’re being upgraded or removed. If a package manager puts full trust in an MSI to always be exactly correct, then it loses complete control over correctly managing file removals.
I could go on and on, with more examples, but “run this binary installer” is the Wild West of putting software on your system. This is mostly the status quo on Windows, but this is a very poor standard. Other operating systems have solved this problem with proper packaging for decades.
When building a package from sources, it makes sense to wrap installers, but then you produce a package that is typically distributed by a mirror. These packages would then by downloaded by you, and contain the source of truth that is trusted to be what it is and that it’ll do what it’s supposed to do without any doubts to consistency and security.
Either the community on GitHub, or someone inside Microsoft.
You can find their repository here (I think most people here are not interested in it tho lol)
I have packaged some software for winget back when I was still using Windows, and yes it runs msi ( or exe ) silently under the hood. Installation processes that are usually done on GUI are automated just like how Homebrew does.