Live data from Hacker News

Packagers don't know best

vagabond.github.io

1–10 of 127 posts

Re: Packagers don't know best

#2
The point of not using embedded libraries isn't about saving space. It's about not having several slightly different versions of the same bug spread out across several slightly different versions of the same library.

Saving space is just a nice side effect, so why not have that too?

The DLL hell problem doesn't exist in a GNU-based system because we have sonames. Windows and Mac OS X don't have those; instead, the software libraries there can't coordinate with each other harmoniously, so each program has to have all of its libraries packaged with its own set of bugs while making a hostile and rude gesture to the rest of the programs in the OS.

Re: Packagers don't know best

#4
post #2

The point of not using embedded libraries isn't about saving space. It's about not having several slightly different versions of the same bug spread out across several slightly different versions of the same library. Saving space is just a nice side effect, so why not have that too? The DLL hell problem doesn't exist in a GNU-based system because we have sonames. Windows and Mac OS X don't have those; instead, the so…

And yet, the Mac OS X user experience is so much nicer than the one you get with a GNU-based system; you download an app, it is self contained, it works, end of story. I have been hearing the same old story for years about how dependency-tracking package managers are the right way, and yet that environment continues to have problems, as described in the article; while the supposedly inferior Mac OS X packaging system just works, and I never have to mess with anything.

I am happy to give up a little extra disk space in exchange for having predictable executables that work in the configuration they were built and tested for.

Re: Packagers don't know best

#5
post #2

The point of not using embedded libraries isn't about saving space. It's about not having several slightly different versions of the same bug spread out across several slightly different versions of the same library. Saving space is just a nice side effect, so why not have that too? The DLL hell problem doesn't exist in a GNU-based system because we have sonames. Windows and Mac OS X don't have those; instead, the so…

And yet, the Mac OS X user experience is so much nicer than the one you get with a GNU-based system; you download an app, it is self contained, it works, end of story. I have been hearing the same old story for years about how dependency-tracking package managers are the right way, and yet that environment continues to have problems, as described in the article; while the supposedly inferior Mac OS X packaging system…

Can you imagine using OSX as a development box without homebrew?

Re: Packagers don't know best

#6

If only Erlang had versioning in modules like other languages do. Modules are hard, most languages get them wrong, and this should be fixed, but you shouldn't blame packagers.

You are missing the point. Even if erlang did support versioning of modules the problem would still exist. Package maintainers arbitrarily break things up because they immediately see a dependency and think it needs to be a separate package. They do this completely ignoring the big picture of shipping solid / tested code.

Re: Packagers don't know best

#7
post #5

Earlier quoted context omitted.

And yet, the Mac OS X user experience is so much nicer than the one you get with a GNU-based system; you download an app, it is self contained, it works, end of story. I have been hearing the same old story for years about how dependency-tracking package managers are the right way, and yet that environment continues to have problems, as described in the article; while the supposedly inferior Mac OS X packaging system…

Can you imagine using OSX as a development box without homebrew?

No, but homebrew doesn't break things up into an insane number of pieces either. In the context of this blog post, Riak on homebrew is a single package.

Re: Packagers don't know best

#8

If only Erlang had versioning in modules like other languages do. Modules are hard, most languages get them wrong, and this should be fixed, but you shouldn't blame packagers.

Erlang applications get versions, and you can specify them when you build releases, which are the Erlang's way of packaging self-executables, through a mechanism that is platform independent.

The thing is, Erlang assumes that things work from said releases, and find the newest available applications in their library path. This makes sense because it is entirely possible for an Erlang application that was upgraded without ever being shut down to want to roll back to older versions.

When this happens, this application has a path with all the libraries and dependencies it ever needed and can rollback to an older one (without shutting down), or start fresh from the newest one automatically.

Other metadata may be added by each release as required.

The thing is that Erlang developers who are experienced and will write and ship products and Erlang will know this and try to build releases and packages that respect this. Then package managers will (often) undo it to fit whatever pattern they have in mind. They did it, for example, with Ubuntu, removing one of the test frameworks that is part of the standard library and setting it in a different package.

Users who tried the language for the first time couldn't run things that depended on the standard library because it was separated in many different packages.

Re: Packagers don't know best

#9
post #2

The point of not using embedded libraries isn't about saving space. It's about not having several slightly different versions of the same bug spread out across several slightly different versions of the same library. Saving space is just a nice side effect, so why not have that too? The DLL hell problem doesn't exist in a GNU-based system because we have sonames. Windows and Mac OS X don't have those; instead, the so…

And yet, the Mac OS X user experience is so much nicer than the one you get with a GNU-based system; you download an app, it is self contained, it works, end of story. I have been hearing the same old story for years about how dependency-tracking package managers are the right way, and yet that environment continues to have problems, as described in the article; while the supposedly inferior Mac OS X packaging system…

For applications its easier for sure. I've always liked how easy it is to installed statically linked applications. Still, bugs happen.

Development libraries, command line utilities, interpreters-- bread-n-butter developement or unixy stuff or in otherwords, the things the average user don't see-- is usually a a lot easier to get and keep up to date when you have a package manager.

Re: Packagers don't know best

#10

If only Erlang had versioning in modules like other languages do. Modules are hard, most languages get them wrong, and this should be fixed, but you shouldn't blame packagers.

Erlang releases appear to be their solution to this.

I fail to understand how, exactly, packagers' choice to not use the release is erlang's (or riak's) fault.

Post reply on HN