[sheepdog-users] About bundling libraries (at least one library isa-l)
Andrew J. Hobbs
ajhobbs at desu.edu
Fri Oct 17 16:00:09 CEST 2014
I'd be against bundling libraries. The team should be able to focus on
sheepdog, but once you fork libraries to bundle them in, you have to
take responsibility for any bugs/exploits against them.
Being an old school Unix guy, I'd rather be responsible for the build
that goes on my servers. While I'd prefer it if sheep was curated in
the main distribution, changes are happening fast enough that's not an
option, and a PPA wouldn't be something I'd trust unless it was
automatic and from the sheepdog team.
I would like to see shepherd resurrected perhaps. Corosync falls over
in practice, and zookeeper has its own idiosyncracies. It would be nice
if that part was native to sheepdog. That could be a project in its own
right, though. So I'll be happy enough to keep on moving with zookeeper
On 10/16/2014 09:35 AM, Marcin Mirosław wrote:
> I'd like to talk about bundling libraries into sheepdog. It has
> advantages and disadvantages, at this moment comes to my mind:
> + stable api, upstream doesn't need to do anything when new version of
> library brings big changes
> +- new version of library can bring performance changes (both
> performance can be increased or decreased;))
> - upstream should track upstream of bundled library to catch stability,
> security fixes
> There are some stories about soft which bundles some libraries, often it
> ends with removing such soft from repositories due to security bugs in
> bundled libs. IMHO (as sysadmin) it's better to not build selfhosted
> soft platform (which brings to my mind behavior of php developers), it's
> better to add new dependency for sheepdog (I mean dependency on isa-l).
> You don't bundle e.g. gcc, userspace-rcu, pkgconfig, fuse and many more.
> What is your opinion?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 353 bytes
More information about the sheepdog-users