microsoft / microsoft/winget-pkgs
[Package Issue]: KDE.Falkon - remove it!
- Dominant language
- No language data
- Stars
- 11.1k
- Forks
- 9.7k
- PR merge metrics
- PR metrics pending
Description
### Please confirm these before moving forward
- [x] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
- [x] I have not been informed if the issue is resolved in a preview version of the winget client.
### Category of the issue
Installation issue.
### Brief description of your issue
There is not stable package that WinGet could reliabley fetch and install.
Thus, it should not lie to users and pretent it does.
### On the surface
You can see the artifact was volatile and 404-prone even before it was added:
https://github.com/microsoft/winget-pkgs/pull/375856#issuecomment-4473931944
It is 404 again today, compare
* https://github.com/microsoft/winget-pkgs/blob/master/manifests/k/KDE/Falkon/26.07.70/KDE.Falkon.installer.yaml
** falkon-master-2608-windows-cl-msvc2022-x86_64.exe
* https://origin.cdn.kde.org/ci-builds/network/falkon/master/windows/
** falkon-master-2626-windows-cl-msvc2022-x86_64.exe
You may patch it out again, but in mere few days it would be 404-ed again, it is whack-the mole game.
### deep dive
While the intention is noble, the contributor clearly does not understand WHAT is CI (continuous integration).
It is a mere check that source code is compileable in master branch, and not a zilch above it.
Snatching "ready to consume" EXE builds out of CI pipelines is a nice lifehack, but it is not something you can give to consumer!
The EXE builds there are not even alpha-quality. They are not supposed to work AT ALL, they are only supposed to indicate (to interested developers if any) did it compile or not, period.
...but maybe, just maybe, that was a "log-structured" append-only CI archive?
Maybe we could get WinGet anchored to some specific branch or tag or commit ID to represent the persistent stable release-quality build artefact???
Well, no again. You can see there is not a single other branch but volatile ever-moving "master" there: https://origin.cdn.kde.org/ci-builds/network/falkon/
### more on Falkon
To compare, when GIMP project got an active and interested user, the latter forked it to a GIMP-for-Windows project and mantained it as stable builds for years, until there a team assembled to re-merge those Windows builds back into GIMP mainline. Similar happenned to GIT itself, with Cygwin/git and MSYS2/git subprojects existing for years and finally got stable enough following (devs community) to be re-merged.
Falkon project though, in its v.7.0x times, raised a call to interested Windows developers/testers and found NOT ONE. So, Falkon explicitly does NOT provide Windows builds for users! See https://www.falkon.org/download/
Even if binary build would be COPIED from KDE/Falkon fleeting CI servers to some DepositFiles-like persistent storage (IPFS? archive.org?) to persistently point WinGet at, there still would be NOT ANY support for the users of it, not even an assumption that that EXE can be started. WinGet would imply the warranties and qualities that never existed. Angry users would come with there issues - where exactly, to WinGet project?
The presented URL is merely CI, a "compilability" check in the vain yet hope one day there MIGHT appear a Windows-centered developer so that hypothetical person would not have to build from zero but rather to pick up the - maybe broken but at least exisitng - source code infrastructure.
### Steps to reproduce
just try to install/update it
### Actual behavior
404, again
### Expected behavior
update to Falkon 7.x happen
### Environment
```raw
irrelevant
```
### Screenshots and Logs
irrelevant
Contributor guide
Research direction
Start with manifests/k/KDE/Falkon/26.07.70/KDE.Falkon.installer.yaml and compare its installer URL with the current KDE Falkon CI directory. Confirm whether the referenced artifact is unavailable and whether a stable Windows release exists; done means removing or replacing the manifest according to the repository’s package-manifest conventions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- yaml
- Domain
- devtools
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100