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

91–100 of 127 posts

Re: Packagers don't know best

#91

Post by zaphar »

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…

Nix is possibly the only system I know of other than maybe homebrew, strangely enough, that has designed itself sanely.

It solves the security issue the space issue, and also the I need special patches for my version of this lib in my unique application.

Re: Packagers don't know best

#92

Post by zaphar »

binarycrusader wrote: post #32
kevingadd wrote: post #18

Earlier quoted context omitted.

You say this guy doesn't know better, but given that he's talking about shipping a security sensitive application that relies on custom tuned, tested forks of libraries, how can you say that he's wrong for not wanting his library fork replaced with some arbitrary version on an end-user's machine? How can that possibly be safer? It's certainly nice to be able to take an existing library an app depends on, patch it to…

So the developer wants to reduce their cost of properly engineering and documenting their application's usage of a particular library in exchange for significantly increasing the costs of rebuilding and updating every software package that uses the same libraries onto the OS developer and their customers?

Who said he didn't properly engineer and document their applications usage of a particular library?

Re: Packagers don't know best

#93

Post by zaphar »

asuffield wrote: post #29
nosequel wrote: post #6

Earlier quoted context omitted.

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.

On the contrary, the people maintaining packages in the distribution are firmly on the side of shipping solid, tested code. That hacked up duplicate of a library that you copied into your source tree? It does not have one hundredth of the testing that has been applied to the version of the library which every other package on the system uses. You have to think about the system as a whole, not assume it is a bootloade…

The answer here is don't package the application using that library then. You'll just ship broken software.

Or....

You can recognize that the author needed those patches to that library and figure out some way to include them.

Re: Packagers don't know best

#94

Post by zaphar »

notacoward wrote: post #36
ochs wrote: post #19

The solution is easy: if you fork a project and it becomes incompatible with the upstream, rename it . How is anyone supposed to discriminate between the two versions if they have the same name? Also, I'd say, if your software needs lots of modified dependencies, you're not communicating with those projects properly. If every single project were to fork every one of their dependencies, the result would be maintenance…

>if your software needs lots of modified dependencies, you're not communicating with those projects properly. This, a hundred times. The OP wants to bundle modified versions of other people's open-source software as part of their own without feeding the changes upstream properly, and that's just not the right way to do things. Distributions' rules discouraging bundled packages are there because even worse things happ…

A change that is only useful to you has little likelihood of being accepted upstream. Changes that are only useful to you are far more frequent than you seem to think.

Re: Packagers don't know best

#95

Post by dvanduzer »

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.

Every organization's needs are different. A large operation like Heroku has a large server footprint, but a very uniform build. A large operation like General Electric might have a large server footprint, but with all sorts of bizarre business requirements that you or I couldn't even imagine.

(I spent the first half of my career in the ISP business.) If I see something as an infrastructure cost that scales slowly but surely, I want a standard distro package wherever I can get one. Sometimes you're in an environment where you've got extremely specific vendor-or-client-imposed requirements, and the best you can hope to do is standardize your configuration / deployment process.

I've had environments where I cared more about CPAN or PyPI than yum or apt (or RHN or roll your own). If I have N00 servers doing the same thing or N00 servers doing a variety of things, the answer shifts.

Re: Packagers don't know best

#96

Post by notacoward »

zaphar wrote: post #94
notacoward wrote: post #36

Earlier quoted context omitted.

>if your software needs lots of modified dependencies, you're not communicating with those projects properly. This, a hundred times. The OP wants to bundle modified versions of other people's open-source software as part of their own without feeding the changes upstream properly, and that's just not the right way to do things. Distributions' rules discouraging bundled packages are there because even worse things happ…

A change that is only useful to you has little likelihood of being accepted upstream. Changes that are only useful to you are far more frequent than you seem to think.

Don't assume you know what I think. I've had to grapple with this issue myself many times. I've had to implement nasty workarounds because upstream rejected a trivial patch. It's a pain, but spewing about how packagers all have OCD and live in the past is hopelessly egocentric and whiny . . . and counterproductive. They do know what they're doing, and their policies generally do make sense if you consider what works across thousands of packages instead of just one. Exceptions and accommodations can be made when the benefit outweighs the cost or risk, but a case has to be made for that. Throwing a tantrum isn't making a case.

Re: Packagers don't know best

#97

Post by YokoZar »

omaranto wrote: post #81
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 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!

Re: Packagers don't know best

#98

Post by tantalor »

zaphar wrote: post #92
binarycrusader wrote: post #32

Earlier quoted context omitted.

So the developer wants to reduce their cost of properly engineering and documenting their application's usage of a particular library in exchange for significantly increasing the costs of rebuilding and updating every software package that uses the same libraries onto the OS developer and their customers?

Who said he didn't properly engineer and document their applications usage of a particular library?

By forking a library, you are not properly using it. You're using something else.

Here "properly engineering and documenting" means pushing upstream changes to officially support your use case, and documenting it so other people know why your use case is important.

Re: Packagers don't know best

#99

Post by gizmo686 »

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).

The developers are still free to package it themselves and distribute installers as .deb, .rpm ETC. If they have a dependency not available in your package manager (or to old a version), they can either also send you that, or have you add their PPA. The only significant problem I see is that their is a fragmented market of packaging systems, which makes it difficult for individual developers to target everyone. Of course *.tar.gz is a good universal installer for when someone doesn't use a major package manager.

Re: Packagers don't know best

#100

Post by mkhattab »

I love that the OP brought up FreeSWITCH because this is one example where I believe it's most troubling for package maintainers, software engineers and system implementers alike. From a software engineer's perspective, including 3rd party libraries in one source tree it transfers the burden of maintenance and support to one project maintainer. Not reinventing the wheel is good and all, but you still have to maintain its integrity.

From a package maintainer's perspective, especially in the case of Debian, they must ensure that packages are stable and secure. It's their job to make sure security updates are released. In the case of FreeSWITCH, there's no distinction between the main source and its dependencies. Package maintainers might as well not bother with including software like FreeSWITCH in their repos or risk the integrity of their system.

System implementer's are mostly ambivalent about these issues until their distro's FreeSWITCH package includes broken dependencies or until their FreeSWITCH installation has a security exploit due to a library that can't be patched independently.

I love FreeSWITCH but I'm sorry to say that it's poorly architected. However, I'm a system implementer, so I don't care.

Post reply on HN