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

111–120 of 127 posts

Re: Packagers don't know best

#111

Post by regularfry »

npsimons wrote: post #46
tmoertel wrote: post #20

The packagers actually do know what’s best. What they do makes patches flow faster not only downstream but also upstream. Improvements and fixes get to more people and get to them faster. Unbundling upstream libraries from downstream projects flattens the change-flow network, reducing the time it takes for things to get fixed and for the fixes to propagate. For example, say that project P uses library L and bundles a…

Yeah, I love how the article is so myopic, they can't imagine a world in which they might be using a package that some other package is also using , therefore, it might need to be upgraded separately from their package . So the author has worked on two large projects that have dependencies, yet he thinks he has the experience to say that splitting a package up (say, into docs, libs and executables) is a bad thing? Ho…

Splitting a package into docs, libs and executables makes a lot of sense. Splitting those further, so you've got umpteen "independent" packages which 95% of users are just going to have to manually recombine to get the functionality the upstream package provides out of the box, can get pathological. Debian has historically been particularly bad at this, and Ubuntu inherited that tendency.

Re: Packagers don't know best

#112

Post by randallsquared »

chc wrote: post #87
randallsquared wrote: post #79

Earlier quoted context omitted.

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…

I can see arguments both ways on things that are technically recoverable but might require lots of download time (like 20GB of games). However, your settings in those games (if not held on Steam's servers; I don't know where they are) should never be deleted by the application. If you're saying that non-recoverable settings and such should go in ~/Documents, I disagree with that, too: things in the Library folders aren't what the users think of as data, but they are stuff that the users will be upset are missing if they uninstall and reinstall.

Re: Packagers don't know best

#113

Post by mwcampbell »

regularfry wrote: post #111
npsimons wrote: post #46

Earlier quoted context omitted.

Yeah, I love how the article is so myopic, they can't imagine a world in which they might be using a package that some other package is also using , therefore, it might need to be upgraded separately from their package . So the author has worked on two large projects that have dependencies, yet he thinks he has the experience to say that splitting a package up (say, into docs, libs and executables) is a bad thing? Ho…

Splitting a package into docs, libs and executables makes a lot of sense. Splitting those further, so you've got umpteen "independent" packages which 95% of users are just going to have to manually recombine to get the functionality the upstream package provides out of the box, can get pathological. Debian has historically been particularly bad at this, and Ubuntu inherited that tendency.

Please give an example of a pathological case in Debian.

Re: Packagers don't know best

#114

Post by mwcampbell »

Having read the arguments on this thread, and having seen the pathologies of a single mega-repository of packages as in Debian (e.g. long release cycles, breaking stability policies for the major web browsers), I think that Ian Murdock's former company Progeny was on the right track with its component-based Debian derivative. As I remember it, the idea was to have a small base system, then have separate components for things like GNOME, Firefox, OpenOffice.org (now LibreOffice), etc.

Meanwhile, Ubuntu's split between main and universe/multiverse is a pretty good compromise. I wouldn't be disappointed if Ubuntu jettisoned universe and multiverse, the better to focus on having a solid main repository, and let a thousand small, focused repositories pick up the slack. As long as all of those repositories leave the packages in main alone, as EPEL does with Red Hat-based systems.

Re: Packagers don't know best

#115

Post by mwcampbell »

dvanduzer wrote: post #106
tmoertel wrote: post #104

Earlier quoted context omitted.

They're not orthogonal; they're two directed graphs with the same vertices and different edges. If the dependency graph G = ( V , E ) has a vertex for every software project and an edge x -> y iff downstream project y depends on upstream project x , then the change-flow network is the graph C = ( V , F ), where there is an edge x -> y in F iff there is a downstream path between x and y in G and also y requires an upd…

I mean, sure, just typeset it in LaTeX and it'll breeze right past your Fortune 500 IT department's change management board.

Meanwhile, organizations too small for a change management board can outsource that function to Debian.

Re: Packagers don't know best

#116

Post by snprbob86 »

chc wrote: post #87
randallsquared wrote: post #79

Earlier quoted context omitted.

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…

Steam itself is sort of a package manager, so that's an interesting edge case...

However, I think that there are basically three categories of application data

1) Documents -- These should never be deleted and are not invisible 2) Settings & other small data not worth deleting, probably nice to keep around in case you ever re-install. Most stuff. 3) Large semi-temporary files, like samples and other downloaded add ons that are optional parts of the application

I think OSX handles 1 & 2 well, but you're right, it needs a way to handle #3 too. However, I think that #2 is a much better default than #3.

Re: Packagers don't know best

#117

Post by snprbob86 »

binarycrusader wrote: post #34
snprbob86 wrote: post #26

Earlier quoted context omitted.

> if you fork a project and it becomes incompatible with the upstream, rename it I agree completely, but I'd like to take your idea further in a direction you likely didn't intend. The fundamental observation of distributed version control systems, in my opinion, is: Every commit is essentially a fork. When you combine these two ideas: 1) fork->rename and 2) change==fork, with the 3) identities & values from FP/Cloju…

Version numbers only appear to be folly because proper engineering discipline has not been applied when managing the stability and/or backwards-compatibility of shared interfaces. If more developers cared about versioning their software appropriately based on incompatible changes or stability guarantees, it would significantly reduce the costs of maintaining OS software distributions and providing integrated software…

> If more developers cared about versioning their software appropriately based on incompatible changes or stability guarantees

But they don't. And you're not going to be able to make them. And even if you did, people would disagree about what constitutes compatibility, stability, and engineering disciplin. One man's "breaking change" is another man's "that was an implementation detail". It's not possible to get this right, since first you need to define "right". That's why versioning is folly.

Re: Packagers don't know best

#118

Post by omaranto »

YokoZar wrote: post #97
omaranto wrote: post #81

Earlier quoted context omitted.

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 l…

Ahh, this is just a simple bug in the command-not-found package that makes those recommendations when you type in a missing binary, not an underlying problem with the entire philosophy of splitting pacakges!

I'm not sure it's really a bug with command-not-found: I think in this case it correctly gives the package containing the erl command, namely erlang-base; the problem is that Ubuntu decided that there should exist an erlang-base package that gives you erl without the standard library.

Re: Packagers don't know best

#119

Post by binarycrusader »

zaphar wrote: post #89
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 cau…

If the developer didn't make it clear the they had essentially forked Erlang or what the component's requirements are, the blame lies with them, not the packager.

If the developer did, then they need to reconsider how difficult their making the lives of their customers by forcing the potential for additional vulnerability exposures on the system.

There's a non-zero cost involved in packaging.

Re: Packagers don't know best

#120

Post by dvanduzer »

mwcampbell wrote: post #115
dvanduzer wrote: post #106

Earlier quoted context omitted.

I mean, sure, just typeset it in LaTeX and it'll breeze right past your Fortune 500 IT department's change management board.

Meanwhile, organizations too small for a change management board can outsource that function to Debian.

Fortune 500 companies use Debian, and mom and pop shops still have to deal with the fact that patches occasionally break critical services.

If you have never in your entire life run `apt-get upgrade` and spent the next four hours wishing you hadn't, then you are quite fortunate. Regardless of the size of your shop, if you're outsourcing patch approval blindly to any distribution, you probably aren't doing anything particularly interesting.

Post reply on HN