thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roger Meier" <>
Subject AW: Thrift debain/ubuntu packages
Date Thu, 01 Dec 2011 20:33:57 GMT
> Von: paul cannon []
> Gesendet: Donnerstag, 1. Dezember 2011 20:02
> On Wed, 30 Nov 2011 21:33 +0100, Roger Meier <>
> wrote:
> > Von: Eric Evans []
> > 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
> > 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
> 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
> packaging the others. In Eric's case, he is motivated to package thrift-
> compiler, python-thrift, and libthrift-java, but not
> (particularly) the others.
Yes, I see the point.
Currently we still have a few languages which depend on files generated
by configure and some language files are generated, so a few packagers need
to build
it with the configure script and not in the style which is common for the

What if we add these folders for others as well, e.g. rpm, windows, osx,
ios, android, etc.?
We would need good glasses to find the src;-)

These are the reasons for me to think one folder should be sufficient.
However, we have Meritocracy and I'm open for all solutions.

The only thing we need now are Debian Packages! 
I already spent some time on that:
It took 1 1/2 years, during that time I got committership and so I became
able to commit it...

> If Eric goes ahead with his packages, I will likely contribute to those,
> 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
> lot of disciplines involved in maintaining packages for all of thrift.
> good PHP packages requires a familiarity with a quite different set of
> and best practices from those for packaging Ruby.
Of course, keep in mind that a few packages still need the configure script.

> > 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
> and Java thrift libraries, but PHP, Ruby, C++, and C# would certainly get
> use as well.
> Yes, people can already use PyPI, easy_install, gem, maven, etc., etc.,
> especially in deployment scenarios it is often much easier to be able to
> 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.
Fully agree, that's why I love Debian!

> p

View raw message