Re: Socket library?
- From: Jay Carlson <nop@xxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Thu, 4 Oct 2012 10:29:58 -0400
On Oct 4, 2012, at 12:57 AM, William Adams wrote:
> If you are a developer that requires certain stuff to be available to run
> your app, you better include it with your app.
Here's a nickel. Get yourself a real distro. (I'm one of those condescending
Ubuntu users! [1])
If you need a single tarball to run on an unspecified Linux system, yes.
Windows, Mac, I can't help you. If you are packaging for Debian stable or
Ubuntu, you should *not* include in-distro binary dependencies. Besides
redundancy etc, you are also losing maintenance; most critically you will not
receive security bug fixes.
If your package is itself going in-distro, this is less of an issue, since your
package can be rebuilt as part of the update. But your package isn't going
in-distro with gratuitous source dependencies.
> For example, if you depend on LuaJIT HEAD,
No software depends on LuaJIT HEAD.
> then having beta 9 available on the machine will not do you much good.
Distinguishing between incompatible library versions is why we have sonames,
which are then reflected in distinct binary packages. If RedHat-like distros
still don't do this right, I've found a new reason to keep ignoring them.
> This might cause even further user confusion if:
> 1) There's no reliable way of checking the version that's already on the
> machine for the features you require.
> 2) There's no package management system to bring things up to date.
If you're packaging a .deb for Ubuntu or Debian, these are not true by
definition.
> Even if there were package management, what's to say that bringing things up
> to date won't break some other app that actually depends on the older version
> that was there.
For structural reasons, Debian and Ubuntu are very unlikely to release packages
which cause this situation; if somebody does and it's not caught, it's a grave
bug and fixed pretty quickly. In my experience, just the structural factors are
enough to keep things like PPAs from screwing stuff up.
> So, just something to think about. Package installs are great, particularly
> if they come with a release. I like the ease with which I can install node
> 0.6.19 instead of having to compile it from scratch. I'll love the same
> about having LuaJIT available for easy apt-get installation. It might not be
> the ultimate solution for specific scenarios though.
There are a few people doing really distro-agnostic binary releases. VMWare had
a strategy of "ship all the libraries, use them if the environment has the
wrong one". This gets kinda painful. (It's better than the bozos who delivered
their own libstdc++ into /usr/lib with a conflicting filename and soname, but
let's not go there.)
I have the luxury of being able to (loosely) specify Debian flavor for most of
my deployments and to be able to deliver as multiple packages. I'm familiar
enough with Debian packaging to be able to ship my own builds of unavailable
backports. I've found it useful to ship multiple packages. Do my packages pass
lintian? Hell no, but as privately distributed pure consumers of infrastructure
this isn't important. I own /opt/nop.com, and my messes are confined to there.
To be fair, I don't know what you're shipping for, and there are a zillion
deployment scenarios; I've had to support random-distro as well as RHEL before.
It was a lot easier to do the Debian packages.
Jay
[1]: I'm OGD (0.93r6 baybeeee) but I don't use Debian unstable for a bunch of
reasons; this means I pretty much bolted for Ubuntu during the era of No
Releases. IMO Debian unstable should have been a lot more unpleasant to use,
since it's not really a solution for anything except people working on Debian
itself. Making it unpleasant would have...focused minds on getting named
releases out the door. I dunno, maybe ban the DPL and more importantly
ftpmasters from using unstable on their main machines except as a VM.
Other related posts:
