10 ms·

Packagers don't know best

119 points by decklin 13y ago

jordigh 13y ago
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.
- marssaxman 13y ago
  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.
  - dman 13y ago
    Can you imagine using OSX as a development box without homebrew?
    - nosequel 13y ago
      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.
    - skybrian 13y ago
      Yes. Never used homebrew. Not sure I'm missing anything.
    - hosay123 13y ago
      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
      - randallsquared 13y ago
        If by "achieved", you mean "aspired to". MacPorts never actually seemed to correctly build the things I needed. Of course, I gave up before 2009.
    - schmonz 13y ago
      Sure, pkgsrc has made it easy to manage third-party software on Mac OS X for over a decade. Lots of other platforms too, with root or without. Homebrew is cool, but I'm pretty happy about being able to use the same package manager everywhere I go.
    - malkia 13y ago
      MacPorts all the way, since it's sane.
  - asperous 13y ago
    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.
  - ghjm 13y ago
    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.
    - dwb 13y ago
      Riak could be contained in one OS X application bundle. All its dependencies in one directory. To uninstall, just trash it. It's up to the distributor.
    - snprbob86 13y ago
      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 now with the app store, that's no longer an issue. And, if you're absolutely anal about deleting every single trace of an app, there are tools that automate the process. For example: http://www.appzapper.com/ http://www.appzapper.com/ -- But really, it's probably a waste of your time unless you had a badly behaved app go rouge. In my many years of Mac ownership, I've installed and uninstalled hundreds of apps and the only time I ever had to bang my head against the wall was when I used to use MacPorts and a Postgres install went haywire because of the same sort of packaging nonsense that the article is talking about.
      - chc 13y ago
        > 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% will just be dead weight without it"?
  - asuffield 13y ago
    Then one day somebody finds a critical bug in zlib and you need to go and fetch an update for every single application you have ever installed on your system. Then it turns out half of them don't have updates.
    - shtylman 13y ago
      This is a fallacy. Just because a bug was exposed in a library you used does not mean your software will be exposed in the same way. Your use of the lib may not even overlap with the bug exposure. And I seriously doubt you carefully comb all the libs you select on a project for "security" before you release something.
      - homeomorphic 13y ago
        Say there's a vulnerability or something in zlib's decompression, as GP suggested. That's gonna affect pretty much all software using zlib (i.e. a LOT). On a system where the package maintainers took care of having all packages use the system zlib, the whole problem is fixed by ONE ENTITY (the zlib maintainer or team) waking up and patching one package. Every user updates the zlib library package through their package manager (which informs them that they need to), and the vulnerability goes away for thousands of programs. If, on the other hand, those thousands of programs all bundled zlib, the user won't be safe until hundreds of maintainers wake up and do (repeatedly the same) patching. Or even worse, if there isn't even a package management system, as some apparently want, the user has to also go fetch the fixed programs from thousands of upstreams. Oh, and the user also has to know about the vulnerability. Not gonna happen! As we can see, the classical model reduces work duplication, reduces patching times and manpower need, and certainly takes a big responsibility off the user's shoulders.
        marssaxman 13y ago
        Funny that you call the packaging scheme the "classical model" - to me that's the "[relatively] new and weird" scheme. I'd say that "everybody builds their own binaries" is the classical model. This is the argument that comes up every time. Perhaps it matters to people who are running complex servers hosting an array of services. In my life, it never comes up. I am either using a personal machine or managing a server which is responsible for one single service. The idea that upgrading one library could affect the behavior of hundreds of programs is terrifying. How do I know they all still work? I don't. I have to go test them all. What this means is that I never update any libraries at all, on a linux machine, because I can't know in advance what the upgrade might break. My concern is not about keeping everything up to date; it is about keeping everything working. If there is a bug in one program then I want to update that program and only that program and no other programs at all. Then I can evaluate the behavior of the new program. If it is worse than the old behavior, I can hopefully go back to the old version. If it is better, then I can keep it. Nothing else should change. This is exactly what I get on Mac OS X, and it's what I get when I build apps with statically linked libraries on Linux: stuff works until I break it, and then I know what I broke, so I can fix it. When I let package managers update things for me, my system becomes an unknowable chaos of changing behavor. Instead, I simply never update anything until I am ready to pave the machine and start from scratch. I install everything I might want to use, then I disable updates and leave it alone until I am ready to start over.
  - dfc 13y ago
    The first thing I do with a new mac is install homebrew.
  - JoshTriplett 13y ago
    > 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. Clearly we have differing requirements. I've found the Debian user experience so much nicer than the one you get on OS X or Windows: you install a package with apt, it pulls in all dependencies, and it Just Works. I consider "self-contained" a bug and a warning sign that makes me start looking for a ten-foot pole; "self-contained" is another way of saying "inconsistent" and "not well integrated".
    - marssaxman 13y ago
      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 anything else on your machine. With Mac OS X, there's generally no installation process at all. You download the app, and you put it where you want it to go, and then you run it, and that's it. Nothing goes anywhere and you don't need any special process to manage it. The experience I've had on Ubuntu is sort of midway between these. There's a complex installation process, and everything has to deal with it, and shit gets plastered all over your machine and there's no way you can keep track of it all, but at least things generally mostly work most of the time. But really: why manage complexity when you can do away with it?
      - schmonz 13y ago
        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.
- ghjm 13y ago
  Just as a point of order, Windows has dynamic library versioning and multiple loading at least as good as sonames. This was first introduced in Windows 2000, 13 years ago.
- brigade 13y ago
  I don't know about Windows, but OS X certainly does have that [1]. It's simply called by a different name. [1] https://developer.apple.com/library/mac/documentation/developertools/conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW20 https://developer.apple.com/library/mac/documentation/develo...
  - malkia 13y ago
    And windows has winSxs - side by side assembly... Then again it's the thing that makes the c:\windows\winsxs folder grow to dozen gigabytes and more (like 9 different versions of msvcr90 which is only for vs2008) Oh, and its the thing that totally stops me from buying surface, since I did "dir /s" on one of the devices at the store
- Afforess 13y ago
  Your argument is disingenuous. While it might prevent a bug from spreading due to older/differing embedded libraries, it is equally likely to cause new bugs, when library signatures change, and some library function is suddenly gone. When you bundle the libraries yourself, you only have to target the libraries you included. When you let the package manager do the magic for you, you have to target every version of the libraries, ever.
  - viraptor 13y ago
    > when library signatures change, and some library function is suddenly gone. No, no, no. This is not how you fix critical / security issues in a well maintained system. You either backport a single patch that fixes the problem without changing any signatures, or if you support a very old, incompatible software you reimplement the fix yourself. Then the release is not a new library. It's the old one + fix. This is what the proper package maintenance is about. No functions should ever be "suddenly gone". Also if you say in your installation requirements "this software requires libfoo >= 1.2.3, < 2.3.4", no sane package maintainer will disagree. Your application may be patched in the packaging process to work with a different supplied version, but most likely it will just get what's needed.
    - homeomorphic 13y ago
      I think this is a key point that many people overlook the importance of when pressuring, say, Debian or Ubuntu maintainers for new package versions inside of a single release.
MostAwesomeDude 13y ago
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.
- nosequel 13y ago
  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.
  - asuffield 13y ago
    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 bootloader for one application.
    - zaphar 13y ago
      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.
- mononcqc 13y ago
  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.
Nux 13y ago
There's also the security factor (that many devs today like to ignore); using shared stuff simplifies it. Maybe packagers don't know best, but neither does this guy.
- kevingadd 13y ago
  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 fix a security hole, and drop that in. But that isn't what's happening in this context...
  - binarycrusader 13y ago
    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?
    - zaphar 13y ago
      Who said he didn't properly engineer and document their applications usage of a particular library?
      - tantalor 13y ago
        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.
m-r-a-m 13y ago
My favorite interesting packaging choice is TeX Live in Fedora 18 [1]. There are about 4500 texlive-* packages (out of around 35000 binary packages in Fedora total). The packagers split up the packages based on upstream metadata. [1] https://bugzilla.redhat.com/show_bug.cgi?id=949626 https://bugzilla.redhat.com/show_bug.cgi?id=949626
- bcl 13y ago
  s/interesting/insane/
  - m-r-a-m 13y ago
    It does sound insane to have so many packages, but it also follows Fedora's policy of staying as close to upstream as possible. The entire package building process is automated since TeX Live provides the packaging metadata with the source. They also include the meta packages [1] so you don't have to install every package individually if disk space is not an issue. [1] https://fedoraproject.org/wiki/Features/TeXLive#Benefit_to_Fedora https://fedoraproject.org/wiki/Features/TeXLive#Benefit_to_F...
  - andor 13y ago
    As a TeX user, I find this extremely useful. The Fedora packages map 1:1 to Texlive packages. There is no need to research if a LaTeX package is available and in which Fedora package it is hidden, you can just install "tex-packagename".
  - homeomorphic 13y ago
    Why is this insane? Seriously, what problems does it cause, hypothetical or otherwise?
mey 13y ago
Along the same issue, see Debian (and as a result Ubuntu) and Ruby Gems. Used to drive me up the wall (until I stopped bothering).
- claudius 13y ago
  Yeah, these Ruby guys releasing incompatible versions every other weekend and expecting to be allowed to blurt their stuff all over the system was rather strange. Good thing Debian provided decent packages.
ochs 13y ago
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 nightmare.
- snprbob86 13y ago
  > 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/Clojure/etc, you realize that version numbers are complete folly. Coincidentally, I just wrote about this with respect to SemVer: http://www.brandonbloom.name/blog/2013/06/19/semver/ http://www.brandonbloom.name/blog/2013/06/19/semver/ In short, if you have awesomelib and make an incompatible version, you can call it awesomelib2. Or you could call it veryawesomelib or whatever else you want. If you give up on the silly idea of being able to compare version numbers, then versioning and naming become equivalent.
  - binarycrusader 13y ago
    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 stacks to users.
    - dragonwriter 13y ago
      > 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. Encoding intelligence (beyond, perhaps, simple sequence) in version numbers for software is fundamentally folly. Encoding intelligence about compatibility in version numbers of APIs is only folly to the extent that "proper engineering discipline has not been applied when managing the stability and/or backwards-compatibility of shared interfaces." Confusing what makes sense with software and what makes sense with APIs is as problematic as any other confusion of interface with implementation.
tmoertel 13y ago
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 slightly modified L in its release. Whenever L’s developers fix or improve or security-patch L, P’s users don’t get the new code. They have to wait for P’s developers to get around to pulling the new code from L, applying their own modifications, and re-releasing P. Packagers say that’s crazy. They ask: Why does P need a modified L? Is it to add fixes or new features? If so, let’s get them into L proper so that L proper will not only meet P’s needs but also provide those fixes and new features to everyone else. Is it because P’s version of L is no longer L but in name? Then let’s stop calling it L and confusing everybody. Fold the no-longer-L into P or release it as a fork of L called M that can have a life of its own. The point is that keeping L out of P makes two things to happen: (1) It ensures that when L’s developers improve L, all users, including P’s downstream users, get those improvements right away. (2) It ensures that when P’s developers improve L, those improvements flow upstream to L quickly and reach all of L’s users, too. More improvements, to more people, faster. That's the idea.
- dvanduzer 13y ago
  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.
  - tmoertel 13y ago
    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 talk to the upstream library developers to get desired changes into the libraries, rather than go the customize-and-bundle route. This improved coordination and patch-flow benefits the users of the libraries and the users of the projects, regardless of whether those users rely on any particular distribution to get the software. Users are, as always, still free to pick whatever distribution best suits their preferences, or no distribution at all. Still, they benefit from the distributions' debundling policy.
mwcampbell 13y ago
I wonder which packagers the author is griping about primarily. I don't see Riak in Debian.
tehwalrus 13y ago
I have two projects which follow different ideas on this (mostly due to size). In both cases, I've basically written "lazy python bindings" for something in C++ (lazy because I only support the features I want in pythonland). Neither of the C++ projects is on github or anything, they're just hosted out there somewhere else (one on SVN, and one only available as archives, I think.) In the archive case, and since the codebase is small, I just included the whole codebase in my git repo, and added a few small cpp, pyx and py files around it. This library already has a fork, and has the most stars (like, 3) of all my github repos - embedding all the required code and statically linking (indeed, compiling) it as part of my `setup.py` works great, and is easy for 3rd party users too. In the SVN case, the main project is huge, like a few hundred MB of source (and they use some crazy code generation, so that's not even the half of it.) It also comes with its own very very basic python driver. So, my approach is to give people two or three small patches, build instructions (the project is a nightmare to build correctly,) and then my python code just installs on its own and talks to the project as a normal python library. This version is useless - it's permanently out of date, I can't even get the build instructions I wrote 3 months ago to work when I'm trying to set it up for someone else, and the whole thing is a massive nightmare. If I'd forked it and provided the huge source tree myself, that would be reduced - but that project is also under active development and it'd be great to actually use their latest, least buggy version! Each of these decisions was made the way it was for real, sensible reasons - I'd hate for a package manager to have to contend with the mess of the second project, and yet apparently that's the way they'd prefer to go with both! Good job no one needs to use any of my code, really.
binarycrusader 13y ago
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 results across systems when performing installations or updates. Likewise, keeping various components from loading multiple copies of the same libraries in memory saves memory, which helps the overall performance of the system. Also, statements like this aren't particularly helpful and are factually inaccurate: So package maintainers, I know you have your particular package manager’s bible codified in 1992 by some grand old hacker beard, and that’s cool. However, that was twenty years ago, software has changed, hardware has changed and maybe it is time to think about these choices again. At least grant us, the developers of the software, the benefit of the doubt. We know how our software works and how it should be packaged. Honest. Some packaging systems are actually fairly new (< 10 years old), and the rules determined for packaging software with that system have actually been determined in the last five years, not twenty years ago as the author claims. Nor are the people working on them grand, old, bearded hackers. OS designers are tasked with providing administrators and the users of the administrated systems with an integrated stack of components tailored and optimised for that OS platform. So developers, by definition, are generally not the ones that know how to best package their software for a given platform. As for documentation not being installed by default? Many people would be surprised at how many administrators care a great deal about not having to install the documentation, header files, or unused locale support on their systems. Every software project has its own view of how its software should be packaged, and while many OS vendors try to respect that, consistency is key to supportability and satisfaction for administrators. So, in summary: * preventing shipping duplicate versions of dependencies can significantly reduce: - maintenance costs (packaging isn't free) - support provision costs (think technical support) - potential exposure to security vulnerabilities - disk space usage (which does actually matter on high multi-tenancy systems) - downtime (less to download and install during updates means system is up and running faster) - potential memory usage (important for multi-tenancy environments or virtualised systems) * administrators expect software to be packaged consistently regardless of the component being packaged * some distributors make packaging choices due to lack of functionality in their packaging system (e.g. -dev and -doc packaging splits) * administrators actually really care about having unused components on their systems, whether that's header files, documentation, or locales * in high multi-tenancy environments (think virtualisation), a 100MB of documentation doesn't sound like much, until you realise that 10 tenants mean 10 copies of docs which is a wasted gigabyte; then consider thousands of virtualised hosts on the same system and now it's suddenly a bit more important * stability and compatibility guarantees may require certain choices that developer may not agree with * supportability requirements may cause differences in build choices developers do not agree with (e.g. compiling with -fno-omit-frame-pointer to guarantee useful core files at minor cost in perf. for 32-bit) I'd like to see the author post a more reasoned blog entry with specific technical concerns that are actually addressable.
dfc 13y ago
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 order to install erlang without erlang-base. I would love to hear how that happened. Splitting things up into multiple packages makes distributions easier to manage. One person can take the lead on package-dev while another person can take the lead on package-doc. Splitting things up into multiple smaller packages also makes distributing fixes a lot easier. With a one line fix to one include would you rather send out the entire erlang environment or just the small package that needed the fix? And yes splitting things up to save storage requirements is most useful for resource constrained devices, not new servers/laptops. But it means that a user who is comfortable with Debian or Fedora on the server/desktop can use their same trusty OS on their next project when the device places serious restrictions on system overhead.
- omaranto 13y ago
  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.
  - YokoZar 13y ago
    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!
    - omaranto 13y ago
JoshTriplett 13y ago
"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 libfoo, not your own fork of libfoo. If you have awesome changes to libfoo, then you should either get them into upstream libfoo, or go all the way and actually fork libfoo into libfooier upstream to allow packaging it separately.
- kiallmacinnes 13y ago
  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.
- dvanduzer 13y ago
  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 packagers should trust developers to make good decisions. (Granted, there are plenty of bad developers and abandonware galore. Packagers are justified in stepping in to make new decisions here.)
  - mwcampbell 13y ago
    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.
schmonz 13y ago
Upstream developers don't know best, either. Packagers sometimes make bad decisions, just like upstream does, because we're all people. "Install our software the way we think you should" is a point of view, but not a very smart one unless it's accompanied by a willingness to be persuaded otherwise. This particular upstream developer clearly hasn't seen an OS-agnostic cross-platform package manager like pkgsrc, where one of the packager's tasks is often to make software more portable than upstream cares to bother with. To take one obvious example, we make sure libtool works on all our supported platforms, and then we make sure software with its own precious all-the-world's-a-Linux way of linking shlibs uses libtool instead. Do we try to feed back our portability fixes upstream? Of course. Does upstream always want them? Of course not. Are they wrong to not care? We sometimes think so. Are we wrong to patch their code? They sometimes think so. They have their goals, we have ours. If anyone reliably knows best about anything, it's users.
grigio 13y ago
i think the right approch is packages for the operative system layer and bundles for the applications. it isnt very smart that a user must be root to install a GUI
malkia 13y ago
There is something to be said about the API's themselves. For example sqlite is backwards compatible (interface-wise), but then my recent worst example was the perforce (p4) client library. It uses C++ and the folks keep changing member variables in the exposed interfaces forcing us to recompile.
andrewflnr 13y ago
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/ http://nixos.org/nix/
- nbouscal 13y ago
  I had never heard of this and it looks awesome, thanks for the link.
- zaphar 13y ago
  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.
mkhattab 13y ago
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.
spullara 13y ago
The real issue with bundling software is that you can't pull in a security patch. You actually have the same issue with internal packages at large companies. If you can stay on the current release you can drastically reduce the effect of security bugs.
mwcampbell 13y ago
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.
jeremiahjordan 13y ago
This is the reason our company creates their own packages and runs our own repositories.

119 points by decklin 13y ago

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.

marssaxman 13y ago
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.
- dman 13y ago
  Can you imagine using OSX as a development box without homebrew?
  - nosequel 13y ago
    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.
  - skybrian 13y ago
    Yes. Never used homebrew. Not sure I'm missing anything.
  - hosay123 13y ago
    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
    - randallsquared 13y ago
      If by "achieved", you mean "aspired to". MacPorts never actually seemed to correctly build the things I needed. Of course, I gave up before 2009.
  - schmonz 13y ago
    Sure, pkgsrc has made it easy to manage third-party software on Mac OS X for over a decade. Lots of other platforms too, with root or without. Homebrew is cool, but I'm pretty happy about being able to use the same package manager everywhere I go.
  - malkia 13y ago
    MacPorts all the way, since it's sane.
- asperous 13y ago
  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.
- ghjm 13y ago
  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.
  - dwb 13y ago
    Riak could be contained in one OS X application bundle. All its dependencies in one directory. To uninstall, just trash it. It's up to the distributor.
  - snprbob86 13y ago
    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 now with the app store, that's no longer an issue. And, if you're absolutely anal about deleting every single trace of an app, there are tools that automate the process. For example: http://www.appzapper.com/ http://www.appzapper.com/ -- But really, it's probably a waste of your time unless you had a badly behaved app go rouge. In my many years of Mac ownership, I've installed and uninstalled hundreds of apps and the only time I ever had to bang my head against the wall was when I used to use MacPorts and a Postgres install went haywire because of the same sort of packaging nonsense that the article is talking about.
    - chc 13y ago
      > 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% will just be dead weight without it"?
- asuffield 13y ago
  Then one day somebody finds a critical bug in zlib and you need to go and fetch an update for every single application you have ever installed on your system. Then it turns out half of them don't have updates.
  - shtylman 13y ago
    This is a fallacy. Just because a bug was exposed in a library you used does not mean your software will be exposed in the same way. Your use of the lib may not even overlap with the bug exposure. And I seriously doubt you carefully comb all the libs you select on a project for "security" before you release something.
    - homeomorphic 13y ago
      Say there's a vulnerability or something in zlib's decompression, as GP suggested. That's gonna affect pretty much all software using zlib (i.e. a LOT). On a system where the package maintainers took care of having all packages use the system zlib, the whole problem is fixed by ONE ENTITY (the zlib maintainer or team) waking up and patching one package. Every user updates the zlib library package through their package manager (which informs them that they need to), and the vulnerability goes away for thousands of programs. If, on the other hand, those thousands of programs all bundled zlib, the user won't be safe until hundreds of maintainers wake up and do (repeatedly the same) patching. Or even worse, if there isn't even a package management system, as some apparently want, the user has to also go fetch the fixed programs from thousands of upstreams. Oh, and the user also has to know about the vulnerability. Not gonna happen! As we can see, the classical model reduces work duplication, reduces patching times and manpower need, and certainly takes a big responsibility off the user's shoulders.
      - marssaxman 13y ago
        Funny that you call the packaging scheme the "classical model" - to me that's the "[relatively] new and weird" scheme. I'd say that "everybody builds their own binaries" is the classical model. This is the argument that comes up every time. Perhaps it matters to people who are running complex servers hosting an array of services. In my life, it never comes up. I am either using a personal machine or managing a server which is responsible for one single service. The idea that upgrading one library could affect the behavior of hundreds of programs is terrifying. How do I know they all still work? I don't. I have to go test them all. What this means is that I never update any libraries at all, on a linux machine, because I can't know in advance what the upgrade might break. My concern is not about keeping everything up to date; it is about keeping everything working. If there is a bug in one program then I want to update that program and only that program and no other programs at all. Then I can evaluate the behavior of the new program. If it is worse than the old behavior, I can hopefully go back to the old version. If it is better, then I can keep it. Nothing else should change. This is exactly what I get on Mac OS X, and it's what I get when I build apps with statically linked libraries on Linux: stuff works until I break it, and then I know what I broke, so I can fix it. When I let package managers update things for me, my system becomes an unknowable chaos of changing behavor. Instead, I simply never update anything until I am ready to pave the machine and start from scratch. I install everything I might want to use, then I disable updates and leave it alone until I am ready to start over.
- dfc 13y ago
  The first thing I do with a new mac is install homebrew.
- JoshTriplett 13y ago
  > 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. Clearly we have differing requirements. I've found the Debian user experience so much nicer than the one you get on OS X or Windows: you install a package with apt, it pulls in all dependencies, and it Just Works. I consider "self-contained" a bug and a warning sign that makes me start looking for a ten-foot pole; "self-contained" is another way of saying "inconsistent" and "not well integrated".
  - marssaxman 13y ago
    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 anything else on your machine. With Mac OS X, there's generally no installation process at all. You download the app, and you put it where you want it to go, and then you run it, and that's it. Nothing goes anywhere and you don't need any special process to manage it. The experience I've had on Ubuntu is sort of midway between these. There's a complex installation process, and everything has to deal with it, and shit gets plastered all over your machine and there's no way you can keep track of it all, but at least things generally mostly work most of the time. But really: why manage complexity when you can do away with it?
    - schmonz 13y ago
      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.
ghjm 13y ago
Just as a point of order, Windows has dynamic library versioning and multiple loading at least as good as sonames. This was first introduced in Windows 2000, 13 years ago.
brigade 13y ago
I don't know about Windows, but OS X certainly does have that [1]. It's simply called by a different name. [1] https://developer.apple.com/library/mac/documentation/developertools/conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW20 https://developer.apple.com/library/mac/documentation/develo...
- malkia 13y ago
  And windows has winSxs - side by side assembly... Then again it's the thing that makes the c:\windows\winsxs folder grow to dozen gigabytes and more (like 9 different versions of msvcr90 which is only for vs2008) Oh, and its the thing that totally stops me from buying surface, since I did "dir /s" on one of the devices at the store
Afforess 13y ago
Your argument is disingenuous. While it might prevent a bug from spreading due to older/differing embedded libraries, it is equally likely to cause new bugs, when library signatures change, and some library function is suddenly gone. When you bundle the libraries yourself, you only have to target the libraries you included. When you let the package manager do the magic for you, you have to target every version of the libraries, ever.
- viraptor 13y ago
  > when library signatures change, and some library function is suddenly gone. No, no, no. This is not how you fix critical / security issues in a well maintained system. You either backport a single patch that fixes the problem without changing any signatures, or if you support a very old, incompatible software you reimplement the fix yourself. Then the release is not a new library. It's the old one + fix. This is what the proper package maintenance is about. No functions should ever be "suddenly gone". Also if you say in your installation requirements "this software requires libfoo >= 1.2.3, < 2.3.4", no sane package maintainer will disagree. Your application may be patched in the packaging process to work with a different supplied version, but most likely it will just get what's needed.
  - homeomorphic 13y ago
    I think this is a key point that many people overlook the importance of when pressuring, say, Debian or Ubuntu maintainers for new package versions inside of a single release.

MostAwesomeDude 13y ago

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.

nosequel 13y ago
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.
- asuffield 13y ago
  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 bootloader for one application.
  - zaphar 13y ago
    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.
mononcqc 13y ago
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.

Nux 13y ago

There's also the security factor (that many devs today like to ignore); using shared stuff simplifies it. Maybe packagers don't know best, but neither does this guy.

kevingadd 13y ago
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 fix a security hole, and drop that in. But that isn't what's happening in this context...
- binarycrusader 13y ago
  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?
  - zaphar 13y ago
    Who said he didn't properly engineer and document their applications usage of a particular library?
    - tantalor 13y ago
      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.

m-r-a-m 13y ago

My favorite interesting packaging choice is TeX Live in Fedora 18 [1]. There are about 4500 texlive-* packages (out of around 35000 binary packages in Fedora total). The packagers split up the packages based on upstream metadata. [1] https://bugzilla.redhat.com/show_bug.cgi?id=949626 https://bugzilla.redhat.com/show_bug.cgi?id=949626

bcl 13y ago
s/interesting/insane/
- m-r-a-m 13y ago
  It does sound insane to have so many packages, but it also follows Fedora's policy of staying as close to upstream as possible. The entire package building process is automated since TeX Live provides the packaging metadata with the source. They also include the meta packages [1] so you don't have to install every package individually if disk space is not an issue. [1] https://fedoraproject.org/wiki/Features/TeXLive#Benefit_to_Fedora https://fedoraproject.org/wiki/Features/TeXLive#Benefit_to_F...
- andor 13y ago
  As a TeX user, I find this extremely useful. The Fedora packages map 1:1 to Texlive packages. There is no need to research if a LaTeX package is available and in which Fedora package it is hidden, you can just install "tex-packagename".
- homeomorphic 13y ago
  Why is this insane? Seriously, what problems does it cause, hypothetical or otherwise?

mey 13y ago

Along the same issue, see Debian (and as a result Ubuntu) and Ruby Gems. Used to drive me up the wall (until I stopped bothering).

claudius 13y ago
Yeah, these Ruby guys releasing incompatible versions every other weekend and expecting to be allowed to blurt their stuff all over the system was rather strange. Good thing Debian provided decent packages.

ochs 13y ago

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

snprbob86 13y ago
> 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/Clojure/etc, you realize that version numbers are complete folly. Coincidentally, I just wrote about this with respect to SemVer: http://www.brandonbloom.name/blog/2013/06/19/semver/ http://www.brandonbloom.name/blog/2013/06/19/semver/ In short, if you have awesomelib and make an incompatible version, you can call it awesomelib2. Or you could call it veryawesomelib or whatever else you want. If you give up on the silly idea of being able to compare version numbers, then versioning and naming become equivalent.
- binarycrusader 13y ago
  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 stacks to users.
  - dragonwriter 13y ago
    > 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. Encoding intelligence (beyond, perhaps, simple sequence) in version numbers for software is fundamentally folly. Encoding intelligence about compatibility in version numbers of APIs is only folly to the extent that "proper engineering discipline has not been applied when managing the stability and/or backwards-compatibility of shared interfaces." Confusing what makes sense with software and what makes sense with APIs is as problematic as any other confusion of interface with implementation.

tmoertel 13y ago

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 slightly modified L in its release. Whenever L’s developers fix or improve or security-patch L, P’s users don’t get the new code. They have to wait for P’s developers to get around to pulling the new code from L, applying their own modifications, and re-releasing P. Packagers say that’s crazy. They ask: Why does P need a modified L? Is it to add fixes or new features? If so, let’s get them into L proper so that L proper will not only meet P’s needs but also provide those fixes and new features to everyone else. Is it because P’s version of L is no longer L but in name? Then let’s stop calling it L and confusing everybody. Fold the no-longer-L into P or release it as a fork of L called M that can have a life of its own. The point is that keeping L out of P makes two things to happen: (1) It ensures that when L’s developers improve L, all users, including P’s downstream users, get those improvements right away. (2) It ensures that when P’s developers improve L, those improvements flow upstream to L quickly and reach all of L’s users, too. More improvements, to more people, faster. That's the idea.

dvanduzer 13y ago
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.
- tmoertel 13y ago
  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 talk to the upstream library developers to get desired changes into the libraries, rather than go the customize-and-bundle route. This improved coordination and patch-flow benefits the users of the libraries and the users of the projects, regardless of whether those users rely on any particular distribution to get the software. Users are, as always, still free to pick whatever distribution best suits their preferences, or no distribution at all. Still, they benefit from the distributions' debundling policy.

mwcampbell 13y ago

I wonder which packagers the author is griping about primarily. I don't see Riak in Debian.

tehwalrus 13y ago

I have two projects which follow different ideas on this (mostly due to size). In both cases, I've basically written "lazy python bindings" for something in C++ (lazy because I only support the features I want in pythonland). Neither of the C++ projects is on github or anything, they're just hosted out there somewhere else (one on SVN, and one only available as archives, I think.) In the archive case, and since the codebase is small, I just included the whole codebase in my git repo, and added a few small cpp, pyx and py files around it. This library already has a fork, and has the most stars (like, 3) of all my github repos - embedding all the required code and statically linking (indeed, compiling) it as part of my `setup.py` works great, and is easy for 3rd party users too. In the SVN case, the main project is huge, like a few hundred MB of source (and they use some crazy code generation, so that's not even the half of it.) It also comes with its own very very basic python driver. So, my approach is to give people two or three small patches, build instructions (the project is a nightmare to build correctly,) and then my python code just installs on its own and talks to the project as a normal python library. This version is useless - it's permanently out of date, I can't even get the build instructions I wrote 3 months ago to work when I'm trying to set it up for someone else, and the whole thing is a massive nightmare. If I'd forked it and provided the huge source tree myself, that would be reduced - but that project is also under active development and it'd be great to actually use their latest, least buggy version! Each of these decisions was made the way it was for real, sensible reasons - I'd hate for a package manager to have to contend with the mess of the second project, and yet apparently that's the way they'd prefer to go with both! Good job no one needs to use any of my code, really.

binarycrusader 13y ago

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 results across systems when performing installations or updates. Likewise, keeping various components from loading multiple copies of the same libraries in memory saves memory, which helps the overall performance of the system. Also, statements like this aren't particularly helpful and are factually inaccurate: So package maintainers, I know you have your particular package manager’s bible codified in 1992 by some grand old hacker beard, and that’s cool. However, that was twenty years ago, software has changed, hardware has changed and maybe it is time to think about these choices again. At least grant us, the developers of the software, the benefit of the doubt. We know how our software works and how it should be packaged. Honest. Some packaging systems are actually fairly new (< 10 years old), and the rules determined for packaging software with that system have actually been determined in the last five years, not twenty years ago as the author claims. Nor are the people working on them grand, old, bearded hackers. OS designers are tasked with providing administrators and the users of the administrated systems with an integrated stack of components tailored and optimised for that OS platform. So developers, by definition, are generally not the ones that know how to best package their software for a given platform. As for documentation not being installed by default? Many people would be surprised at how many administrators care a great deal about not having to install the documentation, header files, or unused locale support on their systems. Every software project has its own view of how its software should be packaged, and while many OS vendors try to respect that, consistency is key to supportability and satisfaction for administrators. So, in summary: * preventing shipping duplicate versions of dependencies can significantly reduce: - maintenance costs (packaging isn't free) - support provision costs (think technical support) - potential exposure to security vulnerabilities - disk space usage (which does actually matter on high multi-tenancy systems) - downtime (less to download and install during updates means system is up and running faster) - potential memory usage (important for multi-tenancy environments or virtualised systems) * administrators expect software to be packaged consistently regardless of the component being packaged * some distributors make packaging choices due to lack of functionality in their packaging system (e.g. -dev and -doc packaging splits) * administrators actually really care about having unused components on their systems, whether that's header files, documentation, or locales * in high multi-tenancy environments (think virtualisation), a 100MB of documentation doesn't sound like much, until you realise that 10 tenants mean 10 copies of docs which is a wasted gigabyte; then consider thousands of virtualised hosts on the same system and now it's suddenly a bit more important * stability and compatibility guarantees may require certain choices that developer may not agree with * supportability requirements may cause differences in build choices developers do not agree with (e.g. compiling with -fno-omit-frame-pointer to guarantee useful core files at minor cost in perf. for 32-bit) I'd like to see the author post a more reasoned blog entry with specific technical concerns that are actually addressable.

dfc 13y ago

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 order to install erlang without erlang-base. I would love to hear how that happened. Splitting things up into multiple packages makes distributions easier to manage. One person can take the lead on package-dev while another person can take the lead on package-doc. Splitting things up into multiple smaller packages also makes distributing fixes a lot easier. With a one line fix to one include would you rather send out the entire erlang environment or just the small package that needed the fix? And yes splitting things up to save storage requirements is most useful for resource constrained devices, not new servers/laptops. But it means that a user who is comfortable with Debian or Fedora on the server/desktop can use their same trusty OS on their next project when the device places serious restrictions on system overhead.

omaranto 13y ago
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.
- YokoZar 13y ago
  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!
  - omaranto 13y ago

JoshTriplett 13y ago

"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 libfoo, not your own fork of libfoo. If you have awesome changes to libfoo, then you should either get them into upstream libfoo, or go all the way and actually fork libfoo into libfooier upstream to allow packaging it separately.

kiallmacinnes 13y ago
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.
dvanduzer 13y ago
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 packagers should trust developers to make good decisions. (Granted, there are plenty of bad developers and abandonware galore. Packagers are justified in stepping in to make new decisions here.)
- mwcampbell 13y ago
  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.

schmonz 13y ago

Upstream developers don't know best, either. Packagers sometimes make bad decisions, just like upstream does, because we're all people. "Install our software the way we think you should" is a point of view, but not a very smart one unless it's accompanied by a willingness to be persuaded otherwise. This particular upstream developer clearly hasn't seen an OS-agnostic cross-platform package manager like pkgsrc, where one of the packager's tasks is often to make software more portable than upstream cares to bother with. To take one obvious example, we make sure libtool works on all our supported platforms, and then we make sure software with its own precious all-the-world's-a-Linux way of linking shlibs uses libtool instead. Do we try to feed back our portability fixes upstream? Of course. Does upstream always want them? Of course not. Are they wrong to not care? We sometimes think so. Are we wrong to patch their code? They sometimes think so. They have their goals, we have ours. If anyone reliably knows best about anything, it's users.

grigio 13y ago

i think the right approch is packages for the operative system layer and bundles for the applications. it isnt very smart that a user must be root to install a GUI

malkia 13y ago

There is something to be said about the API's themselves. For example sqlite is backwards compatible (interface-wise), but then my recent worst example was the perforce (p4) client library. It uses C++ and the folks keep changing member variables in the exposed interfaces forcing us to recompile.

andrewflnr 13y ago

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/ http://nixos.org/nix/

nbouscal 13y ago
I had never heard of this and it looks awesome, thanks for the link.
zaphar 13y ago
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.

mkhattab 13y ago

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.

spullara 13y ago

The real issue with bundling software is that you can't pull in a security patch. You actually have the same issue with internal packages at large companies. If you can stay on the current release you can drastically reduce the effect of security bugs.

mwcampbell 13y ago

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.

jeremiahjordan 13y ago

This is the reason our company creates their own packages and runs our own repositories.