[sldev] Linux variants to support (Re: Projects that I'm working on)

Tofu Linden tofu.linden at lindenlab.com
Tue Apr 14 17:47:23 PDT 2009


Rob Lanphier wrote:
> However, there's also a logistical hurdle that we also have to get over.
> I'm going to guess that some of this is driven by the fact that we run
> Debian Etch on our server infrastructure, and that our build farms and
> common libraries (e.g. the ones we package up and provide, as well as
> use ourselves) are tuned for supporting them. I don't know for sure if
> this is at the heart of the issue, but it's a reason I've at least heard
> before. So, I'm going to let other Lindens on this list speak up about it.

There is a logistical hurdle, but it's probably not - dominantly - this
one; we've (I've) gone to agonising lengths to ensure that the build
farm's toolchain and selection of common libraries does not have much
influence on the library version dependencies of the resulting package.
(A nice side-effect of being able to control version dependencies is
that we can err on the side of conservative [older] version
choices until there is a clear reason to bump them, but this is
not the primary reason.)

The larger hurdle in mandating a really recent Linux
distribution (before we even get to the issue of cutting-off users
on older distros) is in two halves:
* Getting all Linux-enabled devs and QA onto those distributions.
* The resulting homogeny in dev and testing environments is going to
hurt more than help the effectiveness of QA.  Right now having a
good spread of distros for testing is serving us really well for
QA+repros given how burdened QA is.

I'm actually pretty happy to offer *support* for more recent library
features, but I want to keep the generic Linden builds as conservative
and distro-agnostic as possible; this means either dynamic feature
discovery or distro-specific builds.  Both is ideal; I love distro-
specific builds and I'd like them to be the common delivery mechanism
for the Second Life viewer, with the generic Linden builds as a
fallback for other distros.  We're still talking about how this
actually sustainably happens (how it can be automated, how well this
meshes with the packaging policies for various distros, etc).  Input
is always welcome from those with experience in being upstream package
providers.




More information about the SLDev mailing list