Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Packagers don't know best

vagabond.github.io

Post reply on HN
Print view View original

81–90 of 127 posts

Re: Packagers don't know best

#81

Post by omaranto »

dfc wrote: post #33

Look at this ubuntu erlang package, it depends on 40 other packages, as well. That isn’t even the worst of it, if you type ‘erl’ it tells you to install ‘erlang-base’, which only has a handful of dependencies, none of which are any of these erlang libraries! That package is a dummy package that depends on erlang-base and the rest of the base erlang platform. You would have to force dpkg to ignore dependencies in orde…

You misunderstood the point the author made about erlang-base: it's not that he or she somehow installed Erlang without installing erlang-base, but rather that if in an Ubuntu system you try to run 'erl' before installing any Erlang packages at all, you receive a message telling you something like "to get the erl command install the package 'erlang-base'" and if you go and do that, you don't get the Erlang standard library! The point is that Ubuntu should either suggest 'erlang' instead, or not have all those separate tiny packages in the first place.

Re: Packagers don't know best

#82

Post by mwcampbell »

randallsquared wrote: post #75
vacri wrote: post #64

Earlier quoted context omitted.

Then you fall back to this 'superior' individual packaging method. I don't see how this is a counter.

If you packaging partisans manage to convince developers of the merits of your position, the individual packaging method won't be easily available: it'll be "wait for the OS maintainers to decide to include the newer version" or "make; make test; make install" (i.e., be your own packager).

Or you set up pkgsrc under /opt or /usr/pkg or some such, and use that for the software where you want newer versions than your distro provides.

Re: Packagers don't know best

#83

Post by omaranto »

snprbob86 wrote: post #23
ghjm wrote: post #14

Earlier quoted context omitted.

I agree that the Mac packaging system is wonderful for installing programs, but I think this is because it does not even attempt to solve the problem of uninstalling programs. Arguably, this is a good trade-off because users rarely uninstall software. But it means that if you ever become uncertain about the configuration state of a Mac, you're probably going to have to reinstall from scratch.

What?! This is total nonsense. Application uninstalls are as trivial as dragging the application to the trash bin. No, this will not eliminate the application's data from ~/Library, etc, but 98% of the time you don't want that anyway. If you know what you're doing, it's usually a quick `rm -rf ~/Library/...` and you're done. Some poorly behaved apps stick stuff in other places or otherwise muck with your system, but…

That 'go rouge' is a neat typo, it sounds much naughtier than going rogue.

Re: Packagers don't know best

#84

Post by andrewflnr »

I'm going to go ahead and plug the Nix package manager here:

  Nix is a purely functional package manager. This means
  that it can ensure that an upgrade to one package cannot
  break others, that you can always roll back to previous
  version, that multiple versions of a package can coexist
  on the same system, and much more.
So you can all have your own versions of lager or whatever, and still have everything managed sort of nicely. Doesn't solve the "include the docs or not" problem, though. And I'm not sure if it does anything for tmoertel's patching concerns.

http://nixos.org/nix/

Re: Packagers don't know best

#85

Post by drewcrawford »

sounds wrote: post #80
usea wrote: post #68

Earlier quoted context omitted.

I don't want to speak with any authority on this subject since it's mostly foreign to me. However, I will say that your explanation comes with a pretty big assumption: that a library sits on some 2-dimensional spectrum from bad to good. If you don't subscribe to this notion, libraries don't improve; they simply change. If you accept this, then you begin to see why arbitrarily changing parts of a software package with…

Ok, I definitely have a bias toward what the grandparent is saying: flatten the hierarchy. But just from a logical standpoint, couldn't you apply the following equally to the Riak guy who is complaining: "arbitrarily changing parts of a software package without even trying to understand the consequences of those changes is madness" It absolutely is madness. If the Riak guys want to use leveldb in a way Google won't s…

> If the Riak guys want to use leveldb in a way Google won't support, they should rally with the package managers and get Google to stop being "pretend open source."

They don't have any control over Google, by "rallying" or otherwise.

Consider the recent case of the WebKit/blink split. Here you have two sets of some of the world's smartest engineers, who cannot agree about how to render a webpage! And this is a well-defined problem. There are actual standards about how to render webpages! In theory, everybody agrees about what's going on here, and yet it's fork time.

As for what Library X does, there are no standards, and not necessarily does anybody agree about what they are building. And let's be honest here, you probably do not have WebKit-caliber developers hacking on Library X. So the chance that you can arrive at consensus for Library X is much lower than for WebKit/blink.

Meanwhile, instead of dicking around with the will-they-wont-they-merge-upstream committee, you can just ship software that works in practice to people that want to use it. If you are a software developer, and you have the choice between writing software and arguing about it, it is usually a good bet on average to write software.

Re: Packagers don't know best

#86

Post by nbouscal »

mwcampbell wrote: post #73
dvanduzer wrote: post #70

Earlier quoted context omitted.

Reading your comment, I am starting to understand why everyone is so confused about this. Linux and OS X both have the same underlying options for static or shared libraries. There is a large amount of "enterprise" software that is distributed just like a .dmg file. There is plenty of middle ground between having everything dynamically linked and everything statically linked. The author of the article believes that p…

As a sysadmin, which do you prefer: self-contained software distributions with all the dependencies included, or packages that use the host distro's package manager, use system versions of libraries wherever possible, and otherwise integrate well with the host system? The latter seems better to me, but it's an honest question, not rhetorical.

For my boxes I'm at the point of striking a middle ground. I use system versions of libraries wherever possible, but in many cases I compile the actual applications from source. The package manager tends to be too many versions behind, and a lot of the software I use is in active enough development that the difference is actually of significant importance. If the package managers updated more quickly, I'd use them.

Edit: Also, the package managers have an awful habit of installing dependencies that are not actually dependencies. Drives me up a wall.

Re: Packagers don't know best

#87

Post by chc »

randallsquared wrote: post #79
chc wrote: post #42

Earlier quoted context omitted.

> Application uninstalls are as trivial as dragging the application to the trash bin. No, this will not eliminate the application's data from ~/Library, etc, but 98% of the time you don't want that anyway. When uninstalling an application, you usually do want to remove all of the application's components. How often do you say, "You know, I'd like to uninstall 25% of this application, even though the remaining 75% wil…

The two kinds of things there are configuration/settings, and the user data. When you uninstall Adium (for whatever reason), uninstalling the chat logs from the last five years is probably not part of your expected outcome. Uninstalling an application shouldn't reach into your homedir and delete things, either on Linux or OS X.

I do expect when I delete, say, Steam, it won't leave 20 GB of games I can't play sitting around in a totally invisible place. Similarly, when I delete some video or sound editing software, I don't expect it to leave several gigabytes of samples and filters lying around. Both of these are real situations I've encountered when people came to me asking why their hard disk was so ridiculously full.

I can understand not deleting things out of ~/Documents, but a lot of stuff that goes in the Library folders is not what users think of as data that should outlive the application.

Re: Packagers don't know best

#88

Post by zaphar »

sounds wrote: post #80
usea wrote: post #68

Earlier quoted context omitted.

I don't want to speak with any authority on this subject since it's mostly foreign to me. However, I will say that your explanation comes with a pretty big assumption: that a library sits on some 2-dimensional spectrum from bad to good. If you don't subscribe to this notion, libraries don't improve; they simply change. If you accept this, then you begin to see why arbitrarily changing parts of a software package with…

Ok, I definitely have a bias toward what the grandparent is saying: flatten the hierarchy. But just from a logical standpoint, couldn't you apply the following equally to the Riak guy who is complaining: "arbitrarily changing parts of a software package without even trying to understand the consequences of those changes is madness" It absolutely is madness. If the Riak guys want to use leveldb in a way Google won't s…

That's silly. Leveldb is totally open source in every sense of the word. Just because you want to customize it in a way they didn't originally customize it doesn't mean they are "pretending" open source. The fact that they are allowed to customize it in their own custom fork is largely because google is not "pretending".

There are plenty of reasons to ignore patches from outside that are completely valid. Google gets to decide the direction of their fork of leveldb. If a patch doesn't fit that direction they are under no obligation to accept it.

It's not madness for Riak to want a divergent version of a package. Nor is it madness for the package maintainer not to desire to take that package in the direction that Riak wants to. This is why there we have forks in the first place and it's perfectly fine.

In short. No it doesn't equally apply to the Riak guy. The package is responsible for cutting boundaries in the proper place if they don't want to do the work investingating that then they shouldn't package it.

Re: Packagers don't know best

#89

Post by zaphar »

binarycrusader wrote: post #27

While I sympathise with some of the complaints the developer has, the idea that every software component should live as an isolated stack that duplicates its entire set of dependencies is misguided. OS administrators want a maintainable, supportable system that minimises the number of security vulnerabilities they're exposed to and packages software in a consistent fashion. They also want deterministic, repeatable re…

"the idea that every software component should live as an isolated stack that duplicates its entire set of dependencies is misguided"

That's not what he said. He said that packagers frequently break his software for users by incorrectly breaking it up into the wrong pieces and then including a version of that piece that doesn't work. It's especially bad in the case of erlang applications as he enumerates and it's caused by packagers not taking the time to understand the consequences of where they split the software into packages, all in the name having only one version of lib-erl-foo installed on your system.

Re: Packagers don't know best

#90

Post by nbouscal »

andrewflnr wrote: post #84

I'm going to go ahead and plug the Nix package manager here: Nix is a purely functional package manager. This means that it can ensure that an upgrade to one package cannot break others, that you can always roll back to previous version, that multiple versions of a package can coexist on the same system, and much more. So you can all have your own versions of lager or whatever, and still have everything managed sort…

I had never heard of this and it looks awesome, thanks for the link.
Post reply on HN