Embarrassed to say that the only reason I won't try an #Arch based #linux#distro is because I'm so used to #apt I can't bring myself to try another #packagemanager.
Who should be software packaging is a tough problem, I can see the value in #linux distros pushing for better changes downstream, encouraging upstream to change (double click in #KDE) but then I see cases like KeepassXC where the Debian package is now by default broken, actively damaging the reputation of upstream but then I remember #XZ where upstream was left unchecked and hid bad code in plain sight and I go back around in a circle.
Yes, I find reporting to downstream packagers (a.k.a. distributors) extremely relevant! When your favorite #SoftwareCenter or #PackageManager is all for linking to upstream, but not to those who directly affect your package in a supply chain, as a result, tops like in #KeePassXC get all the pinecones: there is no enthusiasm in an average user to link back those issues to downstream, not with the p(l)ain text and how derivatives are communicated anyway... :blobcat_flop_woozy:
As #flatpak has become more popular, I have tried to help make #plugin (s) Flatpak ready.
Interestingly, I keep coming across a general rejection, like "it's not worth the effort", "it's not the future", etc.
I am aware that it has drawbacks. But are you also against it?
Apart from the amount of space it can take up, I have to say that I've never really had any complaints, and I've sort of already accepted it as a kind of convenient, non-system #linux#packagemanager, I guess. #linuxaudio
📦 UPT: Universal Package Management Tool for Linux | It's FOSS
「 A developer called sigoden has created a universal tool called Universal Package-management Tool, or UPT for short, able to put things together in this jungle. Once you have it installed, you won’t need to learn another package management’s lifestyle again 」
Random #pldev and #packagemanager idea: In the build system, developers should explicitly grant permission for packages to execute risky tasks like accessing the filesystem or network. This includes all transitive dependencies. By doing so, any suspicious behavior introduced by updates to dependencies or their dependencies would be apparent.
I am certainly a noob in this area and are not certain whether this can be an effective strategy to mitigate #supplychainattack
@dataelemental@13reak@cjerrington Personally I wasted 15 years of my life with #Windows and I do regret not having made the switch to #Linux 5-10+ years earlier, because Windows to this day doesn't have a good #CLI / #shell nor absolute basics like a #PackageManager to keep stuff updated, so every application has to DIY it's own updates like some Caveman-made Ghettohack of a program...
Over the past 24h I've been restructuring the infant zig.thi.ng repo, added some new data structures, updated all sources to be Zig v0.11 compatible and added Zig package manager support. Took me a lot longer than expected, but already sure the changes & learning will help to accelerate my process (and re-use) on that front...
Since I don't want the extra overhead and don't want to setup & maintain separate Git repos for each of these tools, for now the new structure will be more like Zig's own standard library, sharing a common top-level module namespace ("thi.ng").
Even though there only a few things to use yet (check the readme to see what's there), I've also written some notes how to update your own build files to use these libs with the package manager:
"How did I install application XYZ again? It seems to reside in /opt/... hmm I don't even have #appimagelauncher installed on this machine... so probably a local dpkg..."
@x42@ercanbrack 2/5 I find a future #vision in which the system #packagemanager (e.g. pacman) would only have to manage packages for the #operatingsystem and all #thirdparty#applications (and #plugins?) would be managed via #flatpak, simply put, intriguing. 😇️
On my computers, I already maintain all third party applications via Flatpak, while pacman takes care of the OS.
Manage software programs on your windows device with the awesome tool WinGetUI!
A graphical user interface to manage packages from the most common package managers for windows, such as Winget, Scoop, Chocolatey, Pip, Npm and .NET Tool.
Yes, dear #brew package manager, I definitely did want to upgrade my #hg installation when I’m rebuilding my #Emacs package. You know, the #Mercurial package I had to downgrade every time I tried to update a completely unrelated package.
Does anybody have a recommendation for a #macOS#PackageManager that is less “helpful” and instead simply does what one asks it to do? #HomeBrew’s approach of “oh, this looks a bit outdated so let me ‘help’ you with this” is starting to get on my nerves.
> Orogene is a next-generation package manager for tools that use node_modules/, such as bundlers, CLI tools, and Node.js-based applications. It's fast, robust, and meant to be easily integrated into your workflows such that you never have to worry about whether your node_modules/ is up to date.