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(a)lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/labs-l