On Wed, 30 Nov 2011 21:33 +0100, Roger Meier <ro...@bufferoverflow.ch> wrote: > Von: Eric Evans [mailto:eev...@acunu.com] > Gesendet: Dienstag, 29. November 2011 01:55 > > On my end, I would need the build to create distinct artifacts for each of > > the > > components (compiler and each lib). This also implies that there would need > > to be packaging source (think debian/) for each, instead of just the one > > top- > > level. > Is this really required? Debian allows to have multiple files per target > package > within the debian folder. An additional folder per language will end up in > duplicate > definitions and more work to update etc. > I prefer on folder as we have today => low maintenance effort
It's not required, but it could make it more likely to get good motivated packaging contribution, since typically a single person is responsible for a particular source package (think one debian/ folder). And one person who needs the thrift Perl bindings may be very good at packaging Perl software -- and yet have no need for, skill in, or interest in packaging the others. In Eric's case, he is motivated to package thrift-compiler, python-thrift, and libthrift-java, but not (particularly) the others. If Eric goes ahead with his packages, I will likely contribute to those, and probably pick up a few of the other language pieces. > > The reason for this is that the whole thing covers too many disciplines to > > have a single person (at least this person) maintaining it all throughout a > > Debian release life-cycle. > The people creating the Debian packages would anyway become familiar with > the thrift source tree. And probably use the mailing list here. > The separation of build and install files per language already simplifies > the management of the Debian packages within one debian folder. It's not necessarily the case that Debian packagers would need to become familiar with the entire thrift source tree- the different parts of lib/ are rather nicely self-contained, for the most part. And like Eric said, there are an awful lot of disciplines involved in maintaining packages for all of thrift. Creating good PHP packages requires a familiarity with a quite different set of policies and best practices from those for packaging Ruby. > For many languages people use language specific package formats. > Beside of the thrift-compiler package, what languages do people really need > as a Debian package? In the circles I inhabit, there is an especially strong need for packaged Python and Java thrift libraries, but PHP, Ruby, C++, and C# would certainly get good use as well. Yes, people can already use PyPI, easy_install, gem, maven, etc., etc., but especially in deployment scenarios it is often much easier to be able to bring in Thrift bindings as a depedency of one's OS packages. Getting packages from one's OS vendor also adds the normal benefits of assured OS compatibility, simple security updates, easier system management, and more. p
