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

51–60 of 127 posts

Re: Packagers don't know best

#51

Post by kiallmacinnes »

JoshTriplett wrote: post #44

"I know you have all these rules that try to make packages consistent so sysadmins don't have to give any extra thought to each individual one, but I'm a special snowflake that you should treat differently." I care about having a system with hundreds or thousands of packages installed on it that all work consistently. Linux is not OS X, and packages are not .dmg files; I want your package using the system version of…

This.

Very few people understand the importance, and benefits, when they have never seen anything other than .msi[1], .dmg, or worse, .zip.

[1]: Lets just pretend for a minute that Windows software only comes as plain MSI.. all the various .exe's which splatter stuff all over the disk simply doesn't exist.

Re: Packagers don't know best

#52

Post by schmonz »

marssaxman wrote: post #48
JoshTriplett wrote: post #45

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

I am surprised to see you compare the OS X and Windows experiences. They seem completely dissimilar to me. With Windows, it seems like every little thing needs some complex installer procedure that splats files all over the system. Every program needs dozens of DLLs, and the only way to get rid of it is to run an uninstaller that hopefully remembers everything it created, and even more hopefully doesn't break anythin…

If you think OS X's approach has done away with it, you're wrong. Maybe you've found it a worthwhile tradeoff, but flattening each application's dependency tree is still a tradeoff: you get truly independent applications, but you pay for it in duplication, the costs of which are well enumerated in binarycrusader's post. Maybe you mostly don't encounter those costs. Maybe you even believe most people mostly don't encounter those costs. But they do exist.

Re: Packagers don't know best

#53

Post by hosay123 »

JoshTriplett wrote: post #45
marssaxman wrote: post #4

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…

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

> you install a package with apt, it pulls in all dependencies, and it Just Works

And what happens in the case of a package not available through apt? ("Sorcery! All applications must be packaged! All shared libraries must be packaged individually!")

And there went your afternoon installing some just-slightly-uncommon piece of software

Re: Packagers don't know best

#54

Post by hosay123 »

dman wrote: post #5
marssaxman wrote: post #4

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?

Yes, and my /usr/local isn't a freaking .git repository. Homebrew, bikeshedding what MacPorts achieved a decade previous (and getting it horribly wrong) since 2009

Re: Packagers don't know best

#55

Post by dvanduzer »

tmoertel wrote: post #38
dvanduzer wrote: post #31

Earlier quoted context omitted.

They really don't. This is part of the reason for the plethora of Linux distributions. Some deployments can afford the rapid pace (and consequent instability) of the short term Ubuntu releases or Fedora. Other deployments really do require the longer term stability of the more methodical Ubuntu LTS releases or CentOS / RHEL. Any improvement requires change, but not all changes are an improvement.

I'm not sure I was able to get my point across to you. Let me try another approach. The improvement I'm talking about occurs upsteam of the distributions, even though it is caused by the distributions' packaging policies. Libraries are upstream from projects, and projects are upstream from distributions. If the distributions discourage projects from bundling libraries, this policy will encourage project developers to…

I might be able to comment better if the term "projects" were better defined. It just depends on, well, the nature of the dependencies. Most libraries depend on other libraries. Often at least three layers deep.

If you could explain how your philosophy would deal with, for example, nginx and Apache both depending on libssl, which itself depends on libcrypto, which depends on libz and libc (both of which are also separate independent dependencies of Apache and nginx) then maybe we could discuss it better.

Oh, and in theory I should be able to swap libssl for libgnutls arbitrarily. How do we handle that?

Re: Packagers don't know best

#56

Post by JoshTriplett »

schmonz wrote: post #52
marssaxman wrote: post #48

Earlier quoted context omitted.

I am surprised to see you compare the OS X and Windows experiences. They seem completely dissimilar to me. With Windows, it seems like every little thing needs some complex installer procedure that splats files all over the system. Every program needs dozens of DLLs, and the only way to get rid of it is to run an uninstaller that hopefully remembers everything it created, and even more hopefully doesn't break anythin…

If you think OS X's approach has done away with it, you're wrong. Maybe you've found it a worthwhile tradeoff, but flattening each application's dependency tree is still a tradeoff: you get truly independent applications, but you pay for it in duplication, the costs of which are well enumerated in binarycrusader's post. Maybe you mostly don't encounter those costs. Maybe you even believe most people mostly don't enco…

Exactly. The "self-contained" approach means I can't just upgrade a library once and have everything using it Just Work with the features enabled (or bugs fixed) by the new version.

Re: Packagers don't know best

#57

Post by marssaxman »

JoshTriplett wrote: post #56
schmonz wrote: post #52

Earlier quoted context omitted.

If you think OS X's approach has done away with it, you're wrong. Maybe you've found it a worthwhile tradeoff, but flattening each application's dependency tree is still a tradeoff: you get truly independent applications, but you pay for it in duplication, the costs of which are well enumerated in binarycrusader's post. Maybe you mostly don't encounter those costs. Maybe you even believe most people mostly don't enco…

Exactly. The "self-contained" approach means I can't just upgrade a library once and have everything using it Just Work with the features enabled (or bugs fixed) by the new version.

It's not going to just work all the time. There are so many possible libraries and possible versions of those libraries and their sub-libraries that it is possible, even likely, that nobody in the world has ever tested that precise combination of components before. You don't know whether it's going to work until you try it, and when it doesn't work, it's up to you to figure out what went wrong and fix it. This seems like a monumental waste of time. I would rather use a complete, monolithic application built and tested by the app developer, leave it the way it came, and upgrade it when the app developer has a new, complete, built, and tested version I can use.

Re: Packagers don't know best

#58

Post by vacri »

marssaxman wrote: post #49
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…

> 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. I am the administrator of the machines I use. I am also the user of the machines I use. I care far, far more about my experience as a user than I do as an administrator. The less administrating I have to do the better. As the administrator…

As a user of the machines I use, I value consistency. I don't want to have to hunt down documentation in weird and wonderful places, I want to go to one spot and have it there.

Re: Packagers don't know best

#59

Post by brigade »

JoshTriplett wrote: post #56
schmonz wrote: post #52

Earlier quoted context omitted.

If you think OS X's approach has done away with it, you're wrong. Maybe you've found it a worthwhile tradeoff, but flattening each application's dependency tree is still a tradeoff: you get truly independent applications, but you pay for it in duplication, the costs of which are well enumerated in binarycrusader's post. Maybe you mostly don't encounter those costs. Maybe you even believe most people mostly don't enco…

Exactly. The "self-contained" approach means I can't just upgrade a library once and have everything using it Just Work with the features enabled (or bugs fixed) by the new version.

And the opposite approach means I only need to update glibc once and flash audio is broken.

Re: Packagers don't know best

#60

Post by JoshTriplett »

marssaxman wrote: post #57
JoshTriplett wrote: post #56

Earlier quoted context omitted.

Exactly. The "self-contained" approach means I can't just upgrade a library once and have everything using it Just Work with the features enabled (or bugs fixed) by the new version.

It's not going to just work all the time. There are so many possible libraries and possible versions of those libraries and their sub-libraries that it is possible, even likely, that nobody in the world has ever tested that precise combination of components before. You don't know whether it's going to work until you try it, and when it doesn't work, it's up to you to figure out what went wrong and fix it. This seems…

Personally, I'd prefer a library version tested by a huge number of people running a given distribution than one tested only by the developer of a single package.
Post reply on HN