Hacker News Reader

Comment by r3trohack3r | Hacker News Reader

This is the social commentary where OSS and freedom respecting software intersect. It was called upfront when the split happened.

Don't build FOSS for others. Build it for yourself and package it for others. Expect contributions. It's okay to expect your users to contribute. It's okay to push back and expect them to contribute. It's okay to say no to PRS because you don't have time to review them. It's okay to not have the time to say you don't have the time.

Personally, package management solutions fall short of the FOSS goal for me. Hard to start with a package and float my own changes. Hard to fork and maintain my own version. The whole push for staying on mainline and pushing that burden of the original author is a symptom IMO.

View on HN

Maybe this is a hijack, but IMO current packaging tools/workflows are a big part of the problem here. Forking a Python package to give it a new name is a giant pain, and if you don't rename it and only release it to a private pypi, you're inviting angst and confusion from your internal users. The only alternative is to put your git url and branch directly in a requirements.txt file, which is not remotely scalable.

These kinds of issues exist across npm, homebrew, apt, etc as far as I'm aware.

In contrast, Nix overrides allow patching in fixes at varying degrees of locality, making it trivially easy to maintain a long term fork or just apply unmerged fixes in the short term.

Composer also has a fairly robust patches plugin, I hate other ecosystems that basically require a full fork.

I feel like a fundamental issue is around human-assigned package names and linearly incrementing version numbers. Anyone who graduated from SVN to git understands about using hashes for true object identification, but it seems it's not nearly as widespread in the packaging world, other than for caches and lock files that most users never interact with directly, and rarely-if-ever for enabling nonlinear package evolutions.

Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.

I would not put it on linearly incrementing version numbers, as it is a great label to show known stable git hashes. But version numbers should not be the only way to fetch in packages.

Absolutely, and that's what Nix does. You can of course access anything in nixpkgs by named attribute, and it will have a human readable version number corresponding to the upstream source. But the internal representation is all based on input addressing and hashes.

> Hard to fork and maintain my own version

apt-get source xxxx

put patch in debian/patches

dch --increase

dpkg-buildpackage.

Copy the patch and rebuild next time a new version comes out.

Creating bridges that allow Apt to become the overarching package manager for all sorts of language-specific packages would be extremely interesting.

$ apt rdepends debhelper

Most languages have that already.

> Hard to start with a package and float my own changes.

Easy on Gentoo - https://wiki.gentoo.org/wiki//etc/portage/patches

Reply on news.ycombinator.com