8 ms·

> 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

> 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)

wbl 7y ago
The problem is updating the rust toolchain requires testing all other ports with that dependency to make sure nothing broke.
- jiveturkey 7y ago
  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?
  - int_19h 7y ago
    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.
    - inferiorhuman 7y ago
      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.
nicoburns 7y ago
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.
asveikau 7y ago
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.
- jszymborski 7y ago
  "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-03/ https://www.mozilla.org/en-US/security/advisories/mfsa2020-0... https://www.cisecurity.org/advisory/vulnerability-in-mozilla-firefox-could-allow-for-arbitrary-code-execution_2020-004/ https://www.cisecurity.org/advisory/vulnerability-in-mozilla...
  - asveikau 7y ago
    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.
    - AdamJacobMuller 7y ago
      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.
      - celticmusic 7y ago
        What I find hilarious is that Rust, our lord and saviour, not only didn't prevent the issue, but is actively hampering the fix.
rnhmjoj 7y ago
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 https://github.com/NixOS/nixpkgs/pull/72126
markstos 7y ago
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.
- barrkel 7y ago
  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.
  - jblow 7y ago
    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.
    - klodolph 7y ago
      This isn’t history, the relevant question is what shared libraries are for, not what they were intended to be for.
    - acdha 7y ago
      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.
  - 7y ago

wbl 7y ago

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

jiveturkey 7y ago
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?
- int_19h 7y ago
  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.
  - inferiorhuman 7y ago
    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.

nicoburns 7y ago

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.

asveikau 7y ago

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.

jszymborski 7y ago
"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-03/ https://www.mozilla.org/en-US/security/advisories/mfsa2020-0... https://www.cisecurity.org/advisory/vulnerability-in-mozilla-firefox-could-allow-for-arbitrary-code-execution_2020-004/ https://www.cisecurity.org/advisory/vulnerability-in-mozilla...
- asveikau 7y ago
  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.
  - AdamJacobMuller 7y ago
    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.
    - celticmusic 7y ago
      What I find hilarious is that Rust, our lord and saviour, not only didn't prevent the issue, but is actively hampering the fix.

rnhmjoj 7y ago

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 https://github.com/NixOS/nixpkgs/pull/72126

markstos 7y ago

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.

barrkel 7y ago
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.
- jblow 7y ago
  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.
  - klodolph 7y ago
    This isn’t history, the relevant question is what shared libraries are for, not what they were intended to be for.
  - acdha 7y ago
    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.
- 7y ago