7 ms·

As someone who runs a Linux distribution, please don't vendor your dependencies for the benefit of distribution maintainers, it makes it much more difficult to

As someone who runs a Linux distribution, please don't vendor your dependencies for the benefit of distribution maintainers, it makes it much more difficult to build a coherent system. Running different versions of common libraries causes real annoyances.

Ericson2314 5y ago
Yes this can't be emphasized enough. static linking is fine, I don't really care either way. But please, please don't vendor. The point of software is to be composable, and vendoring kills that. Vendoring will cause free software to drown in its own complexity and is completely irresponsible.
- chris_wot 5y ago
  Could someone explain what is meant by “vendoring”?
  - jrockway 5y ago
    Vendoring is when you just copy the dependencies into your own source tree, like in a third_party directory. Personally, I'm a big fan of just taking what you need. A little copying is better than a little dependency[1]. [1] https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s
  - deleted 5y ago
    [deleted]
  - Ericson2314 5y ago
    It's one a package contains it's dependencies, and often their dependencies too (transitive deps).' packages are supposed to be nodes in a dependency graph (or better, partial order), and there are nice composition rules. But one the nodes themselves represent graph/order closures (or almost-closure) we use that nice property. People that are very application oriented tend to like vendoring --- "my application is its own island, who gives a shit". But the distro's point isn't just gather the software --- that's an anachronism --- but plan a coherent whole. And applications who only care about themselves are terrible for that. The larger point is free and open source software really should be library-first. Siloed Applicationns are a terrible UI and holdover from the economics of proprietary shrink-wrapped software which itself is a skeuomorphism from the physical world of nonreplicable goods.
    - dragonwriter 5y ago
      > Siloed Applicationns are a terrible UI and holdover from the economics of proprietary shrink-wrapped software which itself is a skeuomorphism from the physical world of nonreplicable goods Siloed applications are UI neutral and represent decoupling, which enables progress and resilience. Excessive interdependence is how you lose Google Reader because other services have changed requirements.
      - Ericson2314 5y ago
        What? Getting rid of Google Reader was a business decision. > Siloed applications are UI neutral and represent decoupling, which enables progress and resilience. The medieval manorial economy is resilient. Is that progress? What happened to unified look and feel? and rich interactions between widgets? The smalltalk and Oberon GUI visions? All that requires more integration. I get that we need to make the here and no work, but that is done via the en-mass translation of language-specific package manager packages to distro packages (static or shared, don't care), not vendoring.
        dragonwriter 5y ago
        > What? Getting rid of Google Reader was a business decision It has been widely reported that a significant factor in that business decisions was Google’s massively coupled codebase and the fact that Reader had dependencies on parts of it that were going to have breaking changes to support other services. > The medieval manorial economy is resilient. It’s not, compared to capitalist and modern mixed economies, and unnecessary and counterproductive coupling between unrelated functions is a problem there, too. > Is that progress? Compared to its immediate precedents, generally, yes.
    - sagichmal 5y ago
      Fewer and fewer people are interested in the benefits provided by "coherent whole" distributions. And more and more people are interested in the benefits provided by "it's own island" applications. The future is statically linked and isolated applications. Distros need to adapt.
- vinay_ys 5y ago
  Software is composable - at compile/package time. It doesn't have to be composable at use time.
  - Ericson2314 5y ago
    I agree entirely, but vendoring breaks composition compile/package time by definition! If you have compositional packages you bake into one giant executable or something, that's still not vendoring.
jrockway 5y ago
It's a double-edged sword, though. I find that with Debian I often can't have up-to-date versions of programs I care about, because some program that nobody cares about won't build against an upgraded library version that they mutually depend on. The requirement that every binary on the system depend on the same shared library basically led to things like app stores and Snap, which I think we can all agree that nobody wants.
- drran 5y ago
  It looks like you care about these programs, but you want to have a free ride.
  - jcelerier 5y ago
    a free ride that you indeed can get if you link statically
  - jrockway 5y ago
    Yeah, and I get my free ride by just downloading the binary from the project's website. Linux distributions add a bunch of arbitrary rules that I don't care about and that don't help me.
CJefferson 5y ago
That's easy to say, but sometimes I need to fix bugs in downstream packages, and I am not willing to wait for 6 months (or forever in some cases) for a fix to be released. Then Linux distro a year out my patched censored version and link to the buggy upstream, and I have to keep telling bug reporters to not use the distro version.
- rkeene2 5y ago
  A useful thing to do when forking software is to give it a new name, to make it clear that it's a separate thing. It sounds like you copied some specific version of software you depend on, then forked it, but left the name the same -- which caused confusion by package builders at the distribution since it's a bit of work to determine if you forked the dependency or are just including it for non-distribution user's convenience.

Ericson2314 5y ago

Yes this can't be emphasized enough. static linking is fine, I don't really care either way. But please, please don't vendor. The point of software is to be composable, and vendoring kills that. Vendoring will cause free software to drown in its own complexity and is completely irresponsible.

chris_wot 5y ago
Could someone explain what is meant by “vendoring”?
- jrockway 5y ago
  Vendoring is when you just copy the dependencies into your own source tree, like in a third_party directory. Personally, I'm a big fan of just taking what you need. A little copying is better than a little dependency[1]. [1] https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s
- deleted 5y ago
  [deleted]
- Ericson2314 5y ago
  It's one a package contains it's dependencies, and often their dependencies too (transitive deps).' packages are supposed to be nodes in a dependency graph (or better, partial order), and there are nice composition rules. But one the nodes themselves represent graph/order closures (or almost-closure) we use that nice property. People that are very application oriented tend to like vendoring --- "my application is its own island, who gives a shit". But the distro's point isn't just gather the software --- that's an anachronism --- but plan a coherent whole. And applications who only care about themselves are terrible for that. The larger point is free and open source software really should be library-first. Siloed Applicationns are a terrible UI and holdover from the economics of proprietary shrink-wrapped software which itself is a skeuomorphism from the physical world of nonreplicable goods.
  - dragonwriter 5y ago
    > Siloed Applicationns are a terrible UI and holdover from the economics of proprietary shrink-wrapped software which itself is a skeuomorphism from the physical world of nonreplicable goods Siloed applications are UI neutral and represent decoupling, which enables progress and resilience. Excessive interdependence is how you lose Google Reader because other services have changed requirements.
    - Ericson2314 5y ago
      What? Getting rid of Google Reader was a business decision. > Siloed applications are UI neutral and represent decoupling, which enables progress and resilience. The medieval manorial economy is resilient. Is that progress? What happened to unified look and feel? and rich interactions between widgets? The smalltalk and Oberon GUI visions? All that requires more integration. I get that we need to make the here and no work, but that is done via the en-mass translation of language-specific package manager packages to distro packages (static or shared, don't care), not vendoring.
      - dragonwriter 5y ago
        > What? Getting rid of Google Reader was a business decision It has been widely reported that a significant factor in that business decisions was Google’s massively coupled codebase and the fact that Reader had dependencies on parts of it that were going to have breaking changes to support other services. > The medieval manorial economy is resilient. It’s not, compared to capitalist and modern mixed economies, and unnecessary and counterproductive coupling between unrelated functions is a problem there, too. > Is that progress? Compared to its immediate precedents, generally, yes.
  - sagichmal 5y ago
    Fewer and fewer people are interested in the benefits provided by "coherent whole" distributions. And more and more people are interested in the benefits provided by "it's own island" applications. The future is statically linked and isolated applications. Distros need to adapt.
vinay_ys 5y ago
Software is composable - at compile/package time. It doesn't have to be composable at use time.
- Ericson2314 5y ago
  I agree entirely, but vendoring breaks composition compile/package time by definition! If you have compositional packages you bake into one giant executable or something, that's still not vendoring.

jrockway 5y ago

It's a double-edged sword, though. I find that with Debian I often can't have up-to-date versions of programs I care about, because some program that nobody cares about won't build against an upgraded library version that they mutually depend on. The requirement that every binary on the system depend on the same shared library basically led to things like app stores and Snap, which I think we can all agree that nobody wants.

drran 5y ago
It looks like you care about these programs, but you want to have a free ride.
- jcelerier 5y ago
  a free ride that you indeed can get if you link statically
- jrockway 5y ago
  Yeah, and I get my free ride by just downloading the binary from the project's website. Linux distributions add a bunch of arbitrary rules that I don't care about and that don't help me.

CJefferson 5y ago

That's easy to say, but sometimes I need to fix bugs in downstream packages, and I am not willing to wait for 6 months (or forever in some cases) for a fix to be released. Then Linux distro a year out my patched censored version and link to the buggy upstream, and I have to keep telling bug reporters to not use the distro version.

rkeene2 5y ago
A useful thing to do when forking software is to give it a new name, to make it clear that it's a separate thing. It sounds like you copied some specific version of software you depend on, then forked it, but left the name the same -- which caused confusion by package builders at the distribution since it's a bit of work to determine if you forked the dependency or are just including it for non-distribution user's convenience.