writing.exchange is one of the many independent Mastodon servers you can use to participate in the fediverse.
A small, intentional community for poets, authors, and every kind of writer.

Administered by:

Server stats:

325
active users

#packagemanagement

0 posts0 participants0 posts today

As much as I like flatpak there is still a lot that needs to be improved for it to be a "standard". One of the biggest things is releasing software as a flatpak shouldn't make it "the flatpak version" of the software, it should just be the software that happens to be packaged as a flatpak.

What I mean is no loss of features or hoops to jump through to get it working or extra steps just to use it the same way as downloading it via your distro's package manager.

Too many times there are special steps for the flatpak 'version' of a piece of software to get it working the same.

Since I haven't been porting/packaging much in the last few years, for some reason I thought the situation for package maintainers could have improved... but no 😂

You would think converting a source tarball into a package for some distribution is a solved problem with a smooth process, and maybe I am spoiled by the great experience with #OpenBSD ports, but it still is a real pain for a number of other systems. Are better #PackageManagement tools held hostage by containers?

I'm playing with OpenDevin (github.com/OpenDevin/OpenDevin). Quite an interesting project; I'm definitely impressed. Nevertheless, it took me over an hour to install it. Every time I have to install a non-trivial Python app, I struggle with Python's package management. Throwing a Makefile on top of Poetry (or of npm like JS folks like to do) doesn't help much. I have a dream that one day we'll have sane package management in Python.

GitHubGitHub - OpenDevin/OpenDevin: 🐚 OpenDevin: Code Less, Make More🐚 OpenDevin: Code Less, Make More. Contribute to OpenDevin/OpenDevin development by creating an account on GitHub.
Replied in thread

@BrodieOnLinux I am on Arch because I trust the process they have (I used to lurk the dev public mailing list to see how things go), so binaries from there I trust.

But, in case of the AUR, I prefer to do at least surface level validation on what's going on. This is why I would personally never use an AUR helper that blurs the line between the official repos and the user-uploaded build scripts that is the AUR.