[Labs-l] Maria DB

[Asher Feldman]

I would much rather abandon using debs than use what the debian project has
done to mysql packaging in any production environment. If the discussion
has come down to this, I did WMF a disservice by drifting away from Domas'
optimized "make ; make install ; rsync unstripped binaries to prod"
workflow.

In general, I find environments that don't individually package according
to distro standards every part of their core application stack
that gets built in-house to be more productive, and more responsive to the
needs of developers and ultimately the application. When an ops team
claims that building a recent version of libmemcached for a stable OS is
almost impossibly hard and will take weeks because it requires backporting
a debian maintainers packaging of it for an experimental distro with that
distros unrelated library version dependencies and reliance on a newer
incompatible dpkg tool chain, there's probably something wrong with
that workflow.

I like to rely on Linux distros for the lowest common denominator layer of
the stack and related security updates. The approach that goes into
building and maintaining such a beast are rather different than the
concerns that go into operating a continually developed and deployed
distributed application used by half a billion people.  I don't see a win
in trying to force the two together.

On Thursday, February 14, 2013, Faidon Liambotis wrote:
>
>
> For MySQL/MariaDB, it seems that the Debian packages don't ship a -dbg
> package by default. That's a shame, we can ask for that. As for the rest
> of Asher's changes, I'd love to find a way to make stock packages work
> in our production setup, but I'm not sure if the maintainer would
> welcome the extra complexity of conditionally switching behaviors. We
> can try if you're willing to, Asher :)
>
> Regards,
> Faidon
>
> _______________________________________________
> Labs-l mailing list
> Labs-l at lists.wikimedia.org <javascript:;>
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/labs-l/attachments/20130214/a2b4e8e7/attachment.html>