Hacker News Reader

Comment by smartmic | Hacker News Reader

> being too complicated to package (thanks to cbindgen and rust dependencies)

Can anyone explain what is behind? Is it symptomatic for any programs with those dependency? Especially curious about rust because it seems to be hyped very much lately (I have almost zero rust experience and even less bias about it, just being curious)

View on HN

They don't want to need to update Rust in order to do a presumably small security patch on Firefox.

Which honestly sounds like a totally awesome and legit reason to use -esr. Keep -current current with upstream, stable branch gets patches from firefox-esr.

Keep in mind stable patches to the ports tree are pretty rare on OpenBSD. They didn't do them as binary packages until fairly recently, either.

"presumably small security patch"

The security patch is actually quite severe and has been reported to be in active use.

https://www.mozilla.org/en-US/security/advisories/mfsa2020-0...

https://www.cisecurity.org/advisory/vulnerability-in-mozilla...

I meant small as in code size.

In a stable branch you want the size of changes to be small and targeted despite how severe the issue is. You don't want to take on new bugs from patches that aren't related to issues you want to see fixed.

If the change is so small, I don't see why they wouldn't be able to backport the fix? Don't upgrade firefox (and any dependencies), just fix the bug.

It would be a lot harder if the actual fix was more complicated and a much more complicated diff. Possible that master has diverged sufficiently from their version that backporting the fix would be unreasonable.

If the change is so small, I don't see why they wouldn't be able to backport the fix? Don't upgrade firefox (and any dependencies), just fix the bug.

As far as I understand, you cannot call it Firefox anymore if you deviate from upstream (which is understandable, because upstream doesn't want to get bug reports for custom changes):

https://www.mozilla.org/en-US/foundation/trademarks/distribu...

That's a good point. Perhaps they don't have deep Firefox expertise and resources to test. Perhaps it's better to let Mozilla decide what gets backported to esr and how to do it.

Ah, my mistake :) That makes sense!

Can they not backport the patch to the existing version of Firefox?

No, they'd have to change the name of the browser.

This is the old packaging design where disk space and bandwidth were expensive, so you tried to have one version of each library or package on disk. This design leads to cascading complexity and breakage when many package depend on the same library and some need different versions of the library.

Modern packaging has changed the approach to bundle dependencies-- using more disk space and bandwidth but isolating apps from each other and allowing independent upgrade cycles. Flatpak and Snap work like that and the title wave of interest in containers on servers is related, as server containers are also used to isolate dependency stacks.

Flatpak and Snap are Linux-specific, though. If the BSDs had a comparable solution to package GUI apps along with their dependencies, I presume that Firefox would be one of the first apps to get that treatment.

Shared libraries aren't just about reducing disk space and bandwidth consumption; it's also about fixing bugs in one place fixing it for all consumers. It requires discipline to only fix bugs and not break consumers, though, and therein lies the devil.

Shared libraries just don't work anymore. That's one of the reasons behind Go and containers.

That way, the users always have working applications. Some applications may take more time to be up to date with their dependencies, but at least some of them can be updated asap without worrying about the others.

For example, I use Debian 10 stable on my laptop, on which I installed Snapd. I then installed Firefox with Snap, and I can be confident that Firefox will have the latest security updates, while keeping the system stable (some parts of the system are probably unsecure, but at least everything still work, they will be updated later)

Although, I would like to point that, while the storage space issue is solved with current tech, the bandwidth is still an issue when on mobile data.

The idea of this is great.

On your personal system it probably works really well. In reality tracking thousands of containers on top of operating systems which are using different methodologies gets really complex and in reality isnt ever really done well. At least in my experience. ( granted fortune 100 / 500 never does anything well :) )

What seems to be happening is the burden of the developer to maintain dependencies is now shifted to operations to maintain the automation that manages the various versions of containers because the complexity is too great to do it any other way.

What I see happening in the application of this model is very similar to train wrecks. You see the crash coming for a long time but cant do anything to stop it.

The notion that it's about fixing bugs in one place is revisionist. It's not what people thought they were for when they were introduced.

This isn’t history, the relevant question is what shared libraries are for, not what they were intended to be for.

That’s a really broad claim to toss around with no documentation. It wasn’t true at least as far back as the 1990s and I would especially want a citation for the belief that there was a unified single voice across so many different engineering teams.

It's also about memory consumption.

The same has been proposed in NixOS [1]: basically updating nss, sqlite and other common dependencies for firefox requires recompiling tons of software, which in turn requires testing, especially in the case the update was a major one. NixOS is special in this regard, because the dependencies can be updated just for a specific package, by adding ad-hoc packages for multiple versions, and it's ultimately what has been done for Firefox.

[1]: https://github.com/NixOS/nixpkgs/pull/72126

I don't think it's Rust specific. It's just that distros are very C/C++ centric.

The fast releae cycle of Rust might not help though.

The problem is updating the rust toolchain requires testing all other ports with that dependency to make sure nothing broke.

it wouldn't necessarily. you could just update rust, build firefox and test that. leave the others alone (with older rust).

now if the complaint is solely about rust, not specifically FF, then that's a different story. it might indeed be that FF is the only package using Rust right now?

BSD ports tree can be thought of as versioned as a whole, and packages are basically a snapshot of one particular state of it. If you update one port, and it's a dev dependency for other ports, their packages will reflect that.

Right but you will also find versioned ports e.g. gcc4, gcc5, etc. It's not so unreasonable to assume the maintainers could / would do something similar with rust.

Reply on news.ycombinator.com