6 ms·

I think there’s a difference between “stable” and “evolving”. Software with a much lower release cadence than k8s works well with Debian’s distribution model, b

by orf 6y ago

I think there’s a difference between “stable” and “evolving”. Software with a much lower release cadence than k8s works well with Debian’s distribution model, but it falls down with frequent releases and a large dependency tree. I guess you’d see that with NodeJS applications as well - I don’t think it’s practical for Debian to re-invent NPM and try to distribute and ship the large and changing dependency trees you find in those projects. However that doesn’t mean the software is not _stable_, for the typical definition of stable.

justinclift 6y ago
It kind of feels like the same problem OpenStack had, and failed due to. That being said, OpenStack is technically still around, so it's not completely "dead". ;)
loxs 6y ago
Also I don't get it, what's the problem with shipping a statically linked binary? Yeah, it goes a bit against the debian way, but it will facilitate things like out-of-the-box init scripts etc.
- tremon 6y ago
  Tracking security incidents. If every piece of software uses the system-wide copy of a vulnerable library, you only need to patch that library and the entire system is safe. For every embedded copy of that library, a separate patch and release must be made. That's a lot of management overhead.
  - debiandev 6y ago
    You are confusing static linking with embedding library sources.
    - pabs3 6y ago
      Both static linking and embedded copies have similar issues. With static linking you have to track where the static library ended up (recursively) and then issue rebuilds in the correct order for all packages that contain the static library (directly or indirectly). With embedded copies you have to search the source code archive for the copies and then patch and rebuild each copy. In some ways static linking is more complicated to deal with, due to the case that the static library ends up in some other static library.
- cbmuser 6y ago
  Statically linked means that a vulnerability in one of the libraries means that all statically linked binaries using the library will have to be patched. In case of shared libraries, only the affected library package has to be patched.
- dsr_ 6y ago
  There's no problem with shipping a static binary, except that it means that the binary must be updated specifically every time a security issue or major bug is fixed in a dependency. For a normal major Debian package, a fix to openssl or libc or libgtk-something automatically fixes that bug in the major package as well. For a static binary, Debian has to notice the change, rebuild the static binary, and ship it out. The benefit of a distro is shared, trustable work. Increasing the workload on the distro maintainers is not great, and Debian is an all-volunteer organization, especially sensitive to that workload.
  - debiandev 6y ago
    Correct. Furthermore, rebuilding and distributing a large number of large binaries every time a vulnerability is fixed is harmful! - It encourage users to delay security updates. Hundreds of millions in the world have slow or expensive or capped Internet connectivity. - Makes the distribution unsuitable for many embedded/IoT/industrial/old devices with very limited storage - It gives the impression that the distribution is bloated.
    - jancsika 6y ago
      Debian has an escape valve from its fundamental spirit-defining policies even for non-free software. And if Debian didn't have that policy wrt non-free, I could easily make a similarly general post as you did listing the very real dangers of shipping blobs, which probably carries more weight than the dangers of vendoring you outline. So, why can't there be a repo for the all the vendored things, and make a policy for the maintainers there? By not having that escape valve, the pressure shoots out on the maintainers-- in this example the maintainer's work is made impossible as evidenced by the statements of the previous maintainer that it would take two fulltime devs to package this according to the current policies. So you encourage burnout on your volunteers. This also encourages passive aggressive software design criticisms. Look at the very first comment here that shifts to talking about the "maturity" of the software under discussion. I'd be willing to bet I'd see similar flip judgments on the list discussion of this-- all of which completely ignore the monstrous build systems of the two browsers that Debian ships. So apparently there's an escape valve for exactly two packages, but no policy to generalize that solution for other packages that are the most complex and therefore most likely to burnout your volunteer packagers. Keep in mind you are already on maintainer #2 for this package that still does not ship with Debian because shipping it per current policy is too burdensome. Also notice that you've got a previous maintainer on the list-- who already said this is a two-person job at least-- calling out the current maintainer for being lazy. It seems like a pretty lousy culture if the policy guidelines put policy adherence above respect for your volunteer maintainers.
tremon 6y ago
I think there’s a difference between “stable” and “evolving”. No, that's pretty much the Debian definition of "stable": software that doesn't need changing for multiple years. The Debian term "stable" has nothing to do with whether or not a program crashes regularly, but how often it requires maintenance. In that definition, "evolving" software indeed isn't "stable" (yet).
- Already__Taken 6y ago
  But by that logic no web browser can be in Debian stable.
  - akiselev 6y ago
    From the article: >Beyond Kubernetes, web browsers clearly fall into this category. Distributors have generally given up on trying to backport patches to older browser releases; they just move their users forward to new releases when they happen. The resources to do things any other way just do not exist. Exceptions are already made for browsers, but they're browsers. They're practically essential to 99% of graphical debian installs and don't expose the really nasty unstable bits (like V8's api surface) to the world. I doubt the debian TC will make that exception for devops software with much less mindshare and a public API surface that is the software, at least not on the stable channel.
  - jancsika 6y ago
    Debian just makes an exception for the Firefox and Chromium packages. You can tell that is what the current maintainer was hoping for here. Instead, the previous maintainer-- who literally wrote that it would probably take two full-time devs to properly package this and maintain the package-- goes full Vogon and summons the great Debian bureaucracy to solve this with their poetry.
  - jlgaddis 6y ago
    Note that there is no "firefox" package in Debian stable -- only "firefox-esr".

by orf 6y ago

justinclift 6y ago

It kind of feels like the same problem OpenStack had, and failed due to. That being said, OpenStack is technically still around, so it's not completely "dead". ;)

loxs 6y ago

Also I don't get it, what's the problem with shipping a statically linked binary? Yeah, it goes a bit against the debian way, but it will facilitate things like out-of-the-box init scripts etc.

tremon 6y ago
Tracking security incidents. If every piece of software uses the system-wide copy of a vulnerable library, you only need to patch that library and the entire system is safe. For every embedded copy of that library, a separate patch and release must be made. That's a lot of management overhead.
- debiandev 6y ago
  You are confusing static linking with embedding library sources.
  - pabs3 6y ago
    Both static linking and embedded copies have similar issues. With static linking you have to track where the static library ended up (recursively) and then issue rebuilds in the correct order for all packages that contain the static library (directly or indirectly). With embedded copies you have to search the source code archive for the copies and then patch and rebuild each copy. In some ways static linking is more complicated to deal with, due to the case that the static library ends up in some other static library.
cbmuser 6y ago
Statically linked means that a vulnerability in one of the libraries means that all statically linked binaries using the library will have to be patched. In case of shared libraries, only the affected library package has to be patched.
dsr_ 6y ago
There's no problem with shipping a static binary, except that it means that the binary must be updated specifically every time a security issue or major bug is fixed in a dependency. For a normal major Debian package, a fix to openssl or libc or libgtk-something automatically fixes that bug in the major package as well. For a static binary, Debian has to notice the change, rebuild the static binary, and ship it out. The benefit of a distro is shared, trustable work. Increasing the workload on the distro maintainers is not great, and Debian is an all-volunteer organization, especially sensitive to that workload.
- debiandev 6y ago
  Correct. Furthermore, rebuilding and distributing a large number of large binaries every time a vulnerability is fixed is harmful! - It encourage users to delay security updates. Hundreds of millions in the world have slow or expensive or capped Internet connectivity. - Makes the distribution unsuitable for many embedded/IoT/industrial/old devices with very limited storage - It gives the impression that the distribution is bloated.
  - jancsika 6y ago
    Debian has an escape valve from its fundamental spirit-defining policies even for non-free software. And if Debian didn't have that policy wrt non-free, I could easily make a similarly general post as you did listing the very real dangers of shipping blobs, which probably carries more weight than the dangers of vendoring you outline. So, why can't there be a repo for the all the vendored things, and make a policy for the maintainers there? By not having that escape valve, the pressure shoots out on the maintainers-- in this example the maintainer's work is made impossible as evidenced by the statements of the previous maintainer that it would take two fulltime devs to package this according to the current policies. So you encourage burnout on your volunteers. This also encourages passive aggressive software design criticisms. Look at the very first comment here that shifts to talking about the "maturity" of the software under discussion. I'd be willing to bet I'd see similar flip judgments on the list discussion of this-- all of which completely ignore the monstrous build systems of the two browsers that Debian ships. So apparently there's an escape valve for exactly two packages, but no policy to generalize that solution for other packages that are the most complex and therefore most likely to burnout your volunteer packagers. Keep in mind you are already on maintainer #2 for this package that still does not ship with Debian because shipping it per current policy is too burdensome. Also notice that you've got a previous maintainer on the list-- who already said this is a two-person job at least-- calling out the current maintainer for being lazy. It seems like a pretty lousy culture if the policy guidelines put policy adherence above respect for your volunteer maintainers.

tremon 6y ago

I think there’s a difference between “stable” and “evolving”. No, that's pretty much the Debian definition of "stable": software that doesn't need changing for multiple years. The Debian term "stable" has nothing to do with whether or not a program crashes regularly, but how often it requires maintenance. In that definition, "evolving" software indeed isn't "stable" (yet).

Already__Taken 6y ago
But by that logic no web browser can be in Debian stable.
- akiselev 6y ago
  From the article: >Beyond Kubernetes, web browsers clearly fall into this category. Distributors have generally given up on trying to backport patches to older browser releases; they just move their users forward to new releases when they happen. The resources to do things any other way just do not exist. Exceptions are already made for browsers, but they're browsers. They're practically essential to 99% of graphical debian installs and don't expose the really nasty unstable bits (like V8's api surface) to the world. I doubt the debian TC will make that exception for devops software with much less mindshare and a public API surface that is the software, at least not on the stable channel.
- jancsika 6y ago
  Debian just makes an exception for the Firefox and Chromium packages. You can tell that is what the current maintainer was hoping for here. Instead, the previous maintainer-- who literally wrote that it would probably take two full-time devs to properly package this and maintain the package-- goes full Vogon and summons the great Debian bureaucracy to solve this with their poetry.
- jlgaddis 6y ago
  Note that there is no "firefox" package in Debian stable -- only "firefox-esr".