Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.6
    • Component/s: None
    • Labels:
      None
    • Environment:

      debian stable (etch); probably will work on lenny, but untested

    • Patch Info:
      Patch Available

      Description

      We're using thrift on Debian, so I wanted to have a package for easier
      installation by other users.

      Attached is a patch to add packaging for debian to the
      thrift-20080411p1 release. It includes two bug fixes to make the
      tests work reliably: 1) adding /usr/share/java/commons-lang.jar to the
      search path for the java tests, and 2) sleeping 1 second after
      starting the server for the python tests. If the patch is accepted,
      the maintainer should probably be set to the thrift mailing list,
      rather than the example mailing list address I used.

      1. debian-packaging.patch
        9 kB
        Eric Anderson
      2. THRIFT-71_v10.1.patch
        18 kB
        Yamashita Yuu
      3. THRIFT-71_v10.2.patch
        18 kB
        Yamashita Yuu
      4. THRIFT-71_v10.patch
        18 kB
        Yamashita Yuu
      5. thrift-71_v2.patch
        15 kB
        Esteve Fernandez
      6. thrift-71_v3.patch
        15 kB
        Esteve Fernandez
      7. thrift-71_v4.patch
        16 kB
        Esteve Fernandez
      8. thrift-71_v5.patch
        16 kB
        Esteve Fernandez
      9. thrift-71_v6.patch
        17 kB
        Esteve Fernandez
      10. thrift-71_v7.patch
        17 kB
        Roger Meier
      11. THRIFT-71_v8_0.5.0.patch
        17 kB
        Roger Meier
      12. THRIFT-71_v9.patch
        17 kB
        Jared Bunting
      13. thrift-71.patch
        15 kB
        Esteve Fernandez

        Issue Links

          Activity

          Hide
          David Reiss added a comment -

          Todd, do you want to compare this with what you've got at <http://gitweb.thrift-rpc.org/?p=thrift.git;a=tree;f=debian;h=16f5fd8;hb=c0e3e13>.

          Personally, I don't like the idea of having a debian directory at the top level of the tree. I'd prefer to have either the directory or the patch under contrib. Thoughts?

          Show
          David Reiss added a comment - Todd, do you want to compare this with what you've got at < http://gitweb.thrift-rpc.org/?p=thrift.git;a=tree;f=debian;h=16f5fd8;hb=c0e3e13 >. Personally, I don't like the idea of having a debian directory at the top level of the tree. I'd prefer to have either the directory or the patch under contrib. Thoughts?
          Hide
          Eric Anderson added a comment -

          version 2 of the patch; moves the debian directory under contrib, adds a README that explains how to build the package.

          Show
          Eric Anderson added a comment - version 2 of the patch; moves the debian directory under contrib, adds a README that explains how to build the package.
          Hide
          David Reiss added a comment -

          I'm fine with having this under contrib. I'd still like Todd to compare it to what he did. Also, the non-debian-related diffs in this patch should be separate issues.

          Show
          David Reiss added a comment - I'm fine with having this under contrib. I'd still like Todd to compare it to what he did. Also, the non-debian-related diffs in this patch should be separate issues.
          Hide
          Michael Greene added a comment -

          There is also Esteve's Debian/Ubuntu work at https://launchpad.net/~esteve-fernandez/+archive?field.name_filter=thrift&field.status_filter=published which I'm partial to myself, since it breaks down the libraries properly. I can't really complain about the lack of C#, for the difficulty of Mono packaging on Ubuntu.

          Show
          Michael Greene added a comment - There is also Esteve's Debian/Ubuntu work at https://launchpad.net/~esteve-fernandez/+archive?field.name_filter=thrift&field.status_filter=published which I'm partial to myself, since it breaks down the libraries properly. I can't really complain about the lack of C#, for the difficulty of Mono packaging on Ubuntu.
          Hide
          Esteve Fernandez added a comment -

          Michael: Actually there's a C# package (libthrift-cil), but I don't have much experience with CIL libraries in Debian/Ubuntu, so I don't know if it's packaged properly.

          Anyway, I use that repository for testing purposes, you should use txamqpteam's PPA (https://launchpad.net/~txamqpteam/+archive), which includes a Debian/Ubuntu package for txAMQP. I didn't bother to send the diff because there seemed to be no interest in this issue (last comment was from July) and there are no release plans (Thrift won't be included in Debian unless there's an actual release), but I'll gladly attach it if someone wants to apply it.

          Show
          Esteve Fernandez added a comment - Michael: Actually there's a C# package (libthrift-cil), but I don't have much experience with CIL libraries in Debian/Ubuntu, so I don't know if it's packaged properly. Anyway, I use that repository for testing purposes, you should use txamqpteam's PPA ( https://launchpad.net/~txamqpteam/+archive ), which includes a Debian/Ubuntu package for txAMQP. I didn't bother to send the diff because there seemed to be no interest in this issue (last comment was from July) and there are no release plans (Thrift won't be included in Debian unless there's an actual release), but I'll gladly attach it if someone wants to apply it.
          Hide
          Esteve Fernandez added a comment -

          This patch breaks Thrift down into smaller packages, one for each language library.

          Show
          Esteve Fernandez added a comment - This patch breaks Thrift down into smaller packages, one for each language library.
          Hide
          Esteve Fernandez added a comment -

          The debian directory still resides at the top level in my patch, and I think it's where it should live. It's standard and makes life easier to packagers and builders. For example, we use Launchpad to build our packages, and it expects the debian directory to be at the top level.

          Show
          Esteve Fernandez added a comment - The debian directory still resides at the top level in my patch, and I think it's where it should live. It's standard and makes life easier to packagers and builders. For example, we use Launchpad to build our packages, and it expects the debian directory to be at the top level.
          Hide
          Esteve Fernandez added a comment -

          Newer version of the patch. I had to disable C# support due to THRIFT-264 and THRIFT-272.

          Show
          Esteve Fernandez added a comment - Newer version of the patch. I had to disable C# support due to THRIFT-264 and THRIFT-272 .
          Hide
          Esteve Fernandez added a comment -

          Fixed erlang package.

          Show
          Esteve Fernandez added a comment - Fixed erlang package.
          Hide
          Esteve Fernandez added a comment -

          Reenabled support for C# thanks to THRIFT-309

          Show
          Esteve Fernandez added a comment - Reenabled support for C# thanks to THRIFT-309
          Hide
          Esteve Fernandez added a comment -

          Thanks to Michael (THRIFT-309), my patch has support for C# again, but it still lacks support for the Perl library. Anyway, the rest of the top-tier languages is supported. Any chance of being accepted anytime soon?

          Show
          Esteve Fernandez added a comment - Thanks to Michael ( THRIFT-309 ), my patch has support for C# again, but it still lacks support for the Perl library. Anyway, the rest of the top-tier languages is supported. Any chance of being accepted anytime soon?
          Hide
          David Reiss added a comment -

          I'd like for the three different people who have worked on Debian packaging to come to an agreement on which is best (and incorporate the best features of each). Two of the patches are here, the third is at http://gitweb.thrift-rpc.org/?p=thrift.git;a=tree;f=debian;h=16f5fd8;hb=pri/tlipcon/debian-moved

          I still think that platform-specific packaging information should not be at the top level of the source tree, so if I end up committing this, I'll move the dir under contrib.

          Show
          David Reiss added a comment - I'd like for the three different people who have worked on Debian packaging to come to an agreement on which is best (and incorporate the best features of each). Two of the patches are here, the third is at http://gitweb.thrift-rpc.org/?p=thrift.git;a=tree;f=debian;h=16f5fd8;hb=pri/tlipcon/debian-moved I still think that platform-specific packaging information should not be at the top level of the source tree, so if I end up committing this, I'll move the dir under contrib.
          Hide
          Todd Lipcon added a comment -

          Here are a couple notes:

          • Looks like libthrift-cil is supposed to be libthrift-cli (typo)
          • Should openjdk-6-jdk be a build-depend or just java6-sdk or maybe just java-compiler?
          • Why depend on erlang-nox instead of erlang-base or just erlang?
          • Should we include the examples in the docs package?

          I haven't had a chance to actually try building it, but I'll give that a go later today and report back if I run into any issues. I've got etch and lenny at my disposal and can give both a shot.

          -Todd

          Show
          Todd Lipcon added a comment - Here are a couple notes: Looks like libthrift-cil is supposed to be libthrift-cli (typo) Should openjdk-6-jdk be a build-depend or just java6-sdk or maybe just java-compiler? Why depend on erlang-nox instead of erlang-base or just erlang? Should we include the examples in the docs package? I haven't had a chance to actually try building it, but I'll give that a go later today and report back if I run into any issues. I've got etch and lenny at my disposal and can give both a shot. -Todd
          Hide
          Esteve Fernandez added a comment -

          Looks like libthrift-cil is supposed to be libthrift-cli (typo)

          No, it's not. See e.g libevolution3.0-cil or libnunit2.2-cil

          Should openjdk-6-jdk be a build-depend or just java6-sdk or maybe just java-compiler?

          I chose openjdk-6-jdk because java6-sdk is just a virtual package, but I guess openjdk-6-jdk | java6-sdk is more elegant. However, java-compiler is not enough to compile Thrift, since the latter depends on a JDK library (e.g. jikes wouldn't be able to compile Thrift unless the complete Java library was installed), and it's also a virtual package.

          Why depend on erlang-nox instead of erlang-base or just erlang?

          Because if we depend on erlang, dpkg and apt-get will pull erlang-x11 as well, which isn't actually required. It doesn't explicitly depend on erlang-base as it's already a dependency of erlang-nox

          Should we include the examples in the docs package?

          Sure, I didn't create a package for documentation as it's not particularly complete, but we could simply package examples for the time being.

          I haven't had a chance to actually try building it, but I'll give that a go later today and report back if I run into any issues. I've got etch and lenny at my disposal and can give both a shot.

          Although it's not the real thing (Debian), the Thrift packages build cleanly in Ubuntu Hardy and Intrepid, we regularly publish snapshots at our Launchpad PPA.

          Show
          Esteve Fernandez added a comment - Looks like libthrift-cil is supposed to be libthrift-cli (typo) No, it's not. See e.g libevolution3.0-cil or libnunit2.2-cil Should openjdk-6-jdk be a build-depend or just java6-sdk or maybe just java-compiler? I chose openjdk-6-jdk because java6-sdk is just a virtual package, but I guess openjdk-6-jdk | java6-sdk is more elegant. However, java-compiler is not enough to compile Thrift, since the latter depends on a JDK library (e.g. jikes wouldn't be able to compile Thrift unless the complete Java library was installed), and it's also a virtual package. Why depend on erlang-nox instead of erlang-base or just erlang? Because if we depend on erlang, dpkg and apt-get will pull erlang-x11 as well, which isn't actually required. It doesn't explicitly depend on erlang-base as it's already a dependency of erlang-nox Should we include the examples in the docs package? Sure, I didn't create a package for documentation as it's not particularly complete, but we could simply package examples for the time being. I haven't had a chance to actually try building it, but I'll give that a go later today and report back if I run into any issues. I've got etch and lenny at my disposal and can give both a shot. Although it's not the real thing (Debian), the Thrift packages build cleanly in Ubuntu Hardy and Intrepid, we regularly publish snapshots at our Launchpad PPA.
          Hide
          Esteve Fernandez added a comment -

          Todd: I forgot to mention, that you'll need to apply THRIFT-309 first, as Thrift doesn't build with .NET 2.0 runtimes (like Mono 1.2.6)

          Show
          Esteve Fernandez added a comment - Todd: I forgot to mention, that you'll need to apply THRIFT-309 first, as Thrift doesn't build with .NET 2.0 runtimes (like Mono 1.2.6)
          Hide
          Esteve Fernandez added a comment -

          Depend on openjdk-6-jdk | java-sdk, as per Todd's suggestion.

          Show
          Esteve Fernandez added a comment - Depend on openjdk-6-jdk | java-sdk, as per Todd's suggestion.
          Hide
          Todd Lipcon added a comment - - edited

          Couple more thoughts upon trying to build:

          • The python-all-dbg build depend doesn't seem to exist for etch - it's new in lenny/sid. Removing it causes issues building the libthrift-python-dbg package of course. Not sure what the best course of action is here.
          • Good point on erlang-nox. The build-depend on erlang-base should also be erlang-nox then, since erlang-base-hipe is a valid alternative. Or, we could do erlang-base | erlang-base-hipe. I'm not sure exactly what the dependency structure looks like here and how dpkg satisfies them, but you seem to have a much better grasp than I do
          • Confirmed that openjdk-6-jdk is too specific of a depend above - I don't have that package, but use sun-java6-jdk instead. Doing the | approach seems fine as you suggested.
          • EDITED: had a csharp problem here, but looks like that's just THRIFT-309. Had a race condition with Esteve telling me about it

          I'd like to say we should just drop etch support, but unfortunately Amie Street (and i'm guessing some others) are still deploying on it, so it's a blocker for adopting this deb.

          -Todd

          Show
          Todd Lipcon added a comment - - edited Couple more thoughts upon trying to build: The python-all-dbg build depend doesn't seem to exist for etch - it's new in lenny/sid. Removing it causes issues building the libthrift-python-dbg package of course. Not sure what the best course of action is here. Good point on erlang-nox. The build-depend on erlang-base should also be erlang-nox then, since erlang-base-hipe is a valid alternative. Or, we could do erlang-base | erlang-base-hipe. I'm not sure exactly what the dependency structure looks like here and how dpkg satisfies them, but you seem to have a much better grasp than I do Confirmed that openjdk-6-jdk is too specific of a depend above - I don't have that package, but use sun-java6-jdk instead. Doing the | approach seems fine as you suggested. EDITED: had a csharp problem here, but looks like that's just THRIFT-309 . Had a race condition with Esteve telling me about it I'd like to say we should just drop etch support, but unfortunately Amie Street (and i'm guessing some others) are still deploying on it, so it's a blocker for adopting this deb. -Todd
          Hide
          Esteve Fernandez added a comment - - edited

          The python-all-dbg* stuff should be optional. We could simply have two separate debian/control files, one which depends on it and another one that doesn't, it could be part of a "release" make target.. if we ever make a release

          As for the C# part, I'm not sure if etch could build it after all. It ships with Mono 1.2.2, which IMHO is too old to support /lang:linq, but I don't really know though, I'm no C# expert. Michael is the person to ask Anyway, could you install mono-gmcs from etch-backports and try to build Thrift?

          Show
          Esteve Fernandez added a comment - - edited The python-all-dbg* stuff should be optional. We could simply have two separate debian/control files, one which depends on it and another one that doesn't, it could be part of a "release" make target.. if we ever make a release As for the C# part, I'm not sure if etch could build it after all. It ships with Mono 1.2.2, which IMHO is too old to support /lang:linq, but I don't really know though, I'm no C# expert. Michael is the person to ask Anyway, could you install mono-gmcs from etch-backports and try to build Thrift?
          Hide
          Esteve Fernandez added a comment -

          This patch adds support for Perl

          Show
          Esteve Fernandez added a comment - This patch adds support for Perl
          Hide
          Alexander Shigin added a comment -

          I do believe license file should be changed to Apache one.

          Show
          Alexander Shigin added a comment - I do believe license file should be changed to Apache one.
          Hide
          Todd Lipcon added a comment -

          I don't have a clean patch available at the moment, but I had to make the following changes:

          • Remove libcommons-lang-java and liblog4j1.2-java from build depends now that Ivy is used for the Java lib
          • Get rid of the -Dthrift.extra.cpath in debian/rules
          Show
          Todd Lipcon added a comment - I don't have a clean patch available at the moment, but I had to make the following changes: Remove libcommons-lang-java and liblog4j1.2-java from build depends now that Ivy is used for the Java lib Get rid of the -Dthrift.extra.cpath in debian/rules
          Hide
          Todd Lipcon added a comment -
          Show
          Todd Lipcon added a comment - FYI my branch is in the public repo at: http://thrift-rpc.org/?p=thrift.git;a=shortlog;h=refs/heads/pri/tlipcon/cloudera_deb
          Hide
          kert added a comment -

          How does this fit with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524135 ? Has there been an upload to mentors.debian.net yet ?

          Show
          kert added a comment - How does this fit with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524135 ? Has there been an upload to mentors.debian.net yet ?
          Hide
          Eric Evans added a comment -

          I filed that ITP but haven't done anything with it in quite some time. Esteve and I were going to collaborate and merge our efforts but that never went anywhere either. I think if we're being honest, this issue isn't going anywhere and could safely be closed. Sorry.

          Show
          Eric Evans added a comment - I filed that ITP but haven't done anything with it in quite some time. Esteve and I were going to collaborate and merge our efforts but that never went anywhere either. I think if we're being honest, this issue isn't going anywhere and could safely be closed. Sorry.
          Hide
          Roger Meier added a comment -

          thrift-71_v7.patch is for 0.4.0 release

          see http://www.bufferoverflow.ch/drupal/thrift-debian for buildlog, sources.list and ready to use packages.

          please commit this patch or tell what's wrong with it.
          many people use Debian or one of its derivatives and all of them will like Thrift Debian packages!

          Show
          Roger Meier added a comment - thrift-71_v7.patch is for 0.4.0 release see http://www.bufferoverflow.ch/drupal/thrift-debian for buildlog, sources.list and ready to use packages. please commit this patch or tell what's wrong with it. many people use Debian or one of its derivatives and all of them will like Thrift Debian packages!
          Hide
          Anthony Molinaro added a comment -

          Hi, I'm not a commiter for thrift, so take this as an opinion from the peanut gallery, and nothing more.

          This patch looks like it puts a debian directory at the root of the thrift tree. For the rpm spec file it's in the contrib directory, and looking back through the history of this it seems as though it was in contrib at some point and then pulled out.

          However, I would question the placing of this in thrift at all. Most distributions keep these files separate from the source code distribution. For instance Redhat has their .spec files separate from all the software they package. They don't try to keep the files with the package. The problem with keeping these with the package is there is no one tasked with maintaining them. Doesn't debian have a place where it keeps these packaging specific files? Actually, looking at wikipedia it seems like there is a process for debian packaging http://en.wikipedia.org/wiki/Debian#Package_maintenance
          and it seems like its usually the role of the maintainer of a debian package to take the upstream sources and build a package from them. It does not and probably should not require the upstream package to contain packaging specific configuration.

          Other than that, it seems like the problems with the distribution (ie, commons-lang and python unit test), were fixed and are no longer a problem. So it should be fine for you to keep the debian packaging files wherever you would like and simply use them to build packages, letting the thrift developers know if they break something during the release cycle.

          Alternatively, I think this could be added to contrib with the same guarantees on contrib as everything else which is no guarantees that
          any of it works ever

          Mostly up to the people maintaining the thrift source to decide.

          Show
          Anthony Molinaro added a comment - Hi, I'm not a commiter for thrift, so take this as an opinion from the peanut gallery, and nothing more. This patch looks like it puts a debian directory at the root of the thrift tree. For the rpm spec file it's in the contrib directory, and looking back through the history of this it seems as though it was in contrib at some point and then pulled out. However, I would question the placing of this in thrift at all. Most distributions keep these files separate from the source code distribution. For instance Redhat has their .spec files separate from all the software they package. They don't try to keep the files with the package. The problem with keeping these with the package is there is no one tasked with maintaining them. Doesn't debian have a place where it keeps these packaging specific files? Actually, looking at wikipedia it seems like there is a process for debian packaging http://en.wikipedia.org/wiki/Debian#Package_maintenance and it seems like its usually the role of the maintainer of a debian package to take the upstream sources and build a package from them. It does not and probably should not require the upstream package to contain packaging specific configuration. Other than that, it seems like the problems with the distribution (ie, commons-lang and python unit test), were fixed and are no longer a problem. So it should be fine for you to keep the debian packaging files wherever you would like and simply use them to build packages, letting the thrift developers know if they break something during the release cycle. Alternatively, I think this could be added to contrib with the same guarantees on contrib as everything else which is no guarantees that any of it works ever Mostly up to the people maintaining the thrift source to decide.
          Hide
          David Reiss added a comment -

          I mostly agree with Anthony. I'm fine committing some form of debian packaging files or .diff.gz under contrib, but I don't think it belongs at top level in the distribution.

          Show
          David Reiss added a comment - I mostly agree with Anthony. I'm fine committing some form of debian packaging files or .diff.gz under contrib, but I don't think it belongs at top level in the distribution.
          Hide
          Roger Meier added a comment -

          I'm not really happy with these answers ... why?

          Did you had a look on that mentioned rpm spec file? -> super outdated, could be removed from my perspective.

          Why do we need debian as a top folder here?

          • many years ago people decided to do so
          • building packages is straight forward, no folder moving before building -> e.g. Hudson CI just builds the packages fully automated
          • maintenance is simple, no requirement to move or copy folders before preparing a patch or commit changes
          • similar to the pom.xml for maven
          • many projects are doing the same => provide ready to use packages and having a debian folder within root
          • nobody would like to create and maintain patches within the Debian project as long es we are within incubator

          As you see within that issue, people would like to have Debian packages for Thrift. This would make it super-easy to get started and become familiar with Thrift. I do not believe, that all the people like to do the "./bootstrap.sh; ./configure; make" thing, just to have a quick look or to get started. ... People like to have a solution for their problem, verify if Thrift fits and just us it afterwards.

          I still believe that this project is at Apache to become more popular, mature and widely used.

          Some more questions to consider before you decide or vote on that issue:

          • How do you deploy Thrift to the users within your employer?
          • Should each user build the libraries by himself?
          • Should they use trunk versions and report bug's related to version trunk whatever instead of version 0.4.1?
          • How many time do they spend on such tasks?
          • Fully automated or many manual steps to build and deploy?

          From my perspective the question look's like:
          A) We don't like to have that folder as a top folder.
          B) People should be able to use Thrift as easy and fast as possible.

          If you think nobody maintains that patch...
          now this patch has version 7 and there are many people here ready to maintain that directory.

          The same for me, I'm ready to maintain the Debian support for Thrift, setup CI as I did already at home and contribute to the test framework, Java Script language support, etc.

          So please go for answer B and commit that patch

          Show
          Roger Meier added a comment - I'm not really happy with these answers ... why? Did you had a look on that mentioned rpm spec file? -> super outdated, could be removed from my perspective. Why do we need debian as a top folder here? many years ago people decided to do so building packages is straight forward, no folder moving before building -> e.g. Hudson CI just builds the packages fully automated maintenance is simple, no requirement to move or copy folders before preparing a patch or commit changes similar to the pom.xml for maven many projects are doing the same => provide ready to use packages and having a debian folder within root nobody would like to create and maintain patches within the Debian project as long es we are within incubator As you see within that issue, people would like to have Debian packages for Thrift. This would make it super-easy to get started and become familiar with Thrift. I do not believe, that all the people like to do the "./bootstrap.sh; ./configure; make" thing, just to have a quick look or to get started. ... People like to have a solution for their problem, verify if Thrift fits and just us it afterwards. I still believe that this project is at Apache to become more popular, mature and widely used . Some more questions to consider before you decide or vote on that issue: How do you deploy Thrift to the users within your employer? Should each user build the libraries by himself? Should they use trunk versions and report bug's related to version trunk whatever instead of version 0.4.1? How many time do they spend on such tasks? Fully automated or many manual steps to build and deploy? From my perspective the question look's like: A) We don't like to have that folder as a top folder. B) People should be able to use Thrift as easy and fast as possible. If you think nobody maintains that patch... now this patch has version 7 and there are many people here ready to maintain that directory. The same for me, I'm ready to maintain the Debian support for Thrift, setup CI as I did already at home and contribute to the test framework, Java Script language support, etc. So please go for answer B and commit that patch
          Hide
          Thomas Koch added a comment -

          Wouldn't it be the easiest thing to do to help Eric Evans to get thrift into Debian? Just look again at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524135

          Show
          Thomas Koch added a comment - Wouldn't it be the easiest thing to do to help Eric Evans to get thrift into Debian? Just look again at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524135
          Hide
          Bryan Duxbury added a comment -

          I am mostly in favor of just doing something at this point. As long as adding the patch doesn't get in the way of anything we do today, then I'm fine with us committing what we have.

          Show
          Bryan Duxbury added a comment - I am mostly in favor of just doing something at this point. As long as adding the patch doesn't get in the way of anything we do today, then I'm fine with us committing what we have.
          Hide
          Roger Meier added a comment -

          please commit this!

          I would like to merge Eric Evans patches from http://git.debian.org/?p=collab-maint/thrift.git with latest patch thrift-71_v7.patch hopefully before 0.5 release, but we need a starting point within repo.

          The important thing is, that we can at least deploy Thrift compiler as Debian package with each release, just as we do with win32 Thrift Compiler or Maven.

          On Question for me is:
          how do we get the VERSION define from config.h to relevant files for each release?
          e.g. lib/csharp/ThriftMSBuildTask/Properties/AssemblyInfo.cs

          debian/changelog has to be edited manually for each release, but the rest should be fully automated.

          Show
          Roger Meier added a comment - please commit this! I would like to merge Eric Evans patches from http://git.debian.org/?p=collab-maint/thrift.git with latest patch thrift-71_v7.patch hopefully before 0.5 release, but we need a starting point within repo. The important thing is, that we can at least deploy Thrift compiler as Debian package with each release, just as we do with win32 Thrift Compiler or Maven. On Question for me is: how do we get the VERSION define from config.h to relevant files for each release? e.g. lib/csharp/ThriftMSBuildTask/Properties/AssemblyInfo.cs debian/changelog has to be edited manually for each release, but the rest should be fully automated.
          Hide
          Roger Meier added a comment -

          just added THRIFT-71_v8_0.5.0.patch, result can be tested by adding the following lines to /etc/apt/sources.list.d/thrift.list on a Debian based GNU/Linux

          deb http://people.apache.org/~roger/dist/thrift/0.5.0/debian stable contrib
          deb-src http://people.apache.org/~roger/dist/thrift/0.5.0/debian stable contrib
          

          right now, I tested only the thrift-compiler package...other tests are welcome!

          versioning, package description text, etc. will be harmonized across all distributions (Python, Debian, Maven, Windows, etc.) via THRIFT-6

          @Esteve:

          • Can we change the maintainer address from your to thrift-dev@incubator.apache.org?
          • Could you agree if we change Debian package License from BSD to Apache 2.0 ?

          I'm ready to change little things and then commit this, so please VOTE now!

          Show
          Roger Meier added a comment - just added THRIFT-71_v8_0.5.0.patch , result can be tested by adding the following lines to /etc/apt/sources.list.d/thrift.list on a Debian based GNU/Linux deb http: //people.apache.org/~roger/dist/thrift/0.5.0/debian stable contrib deb-src http: //people.apache.org/~roger/dist/thrift/0.5.0/debian stable contrib right now, I tested only the thrift-compiler package...other tests are welcome! versioning, package description text, etc. will be harmonized across all distributions (Python, Debian, Maven, Windows, etc.) via THRIFT-6 @Esteve: Can we change the maintainer address from your to thrift-dev@incubator.apache.org? Could you agree if we change Debian package License from BSD to Apache 2.0 ? I'm ready to change little things and then commit this, so please VOTE now!
          Hide
          David Reiss added a comment -

          I vote -1 to putting a debian-specific directory at the top level of the Thrift source tree. If everyone else is against me on this, I'll give in, but it seems like bad practice to clutter up the top level of our tree with system-specific stuff.

          Show
          David Reiss added a comment - I vote -1 to putting a debian-specific directory at the top level of the Thrift source tree. If everyone else is against me on this, I'll give in, but it seems like bad practice to clutter up the top level of our tree with system-specific stuff.
          Hide
          Esteve Fernandez added a comment -

          @Roger

          Sure, +1 to both

          @David

          I think you're right, the Debian packaging guide says something about it's better not having a debian directory at the top level. However, the important thing is that the debian directory should not be shipped with the release tarball, but in a separate diff.

          Show
          Esteve Fernandez added a comment - @Roger Sure, +1 to both @David I think you're right, the Debian packaging guide says something about it's better not having a debian directory at the top level. However, the important thing is that the debian directory should not be shipped with the release tarball, but in a separate diff.
          Hide
          Akira Kitada added a comment -

          Isn't fb303 included in this package or should it be separate 'fb303' 'python-fb303' etc?

          Show
          Akira Kitada added a comment - Isn't fb303 included in this package or should it be separate 'fb303' 'python-fb303' etc?
          Hide
          Jared Bunting added a comment -

          I ran into two small problems with the patch so I'm attaching my modifications.

          1. I know that this patch is intended for the source tree, but when applied to the source tarball, debian/rules doesn't work due to invoking bootstrap.sh. So, I've changed the invocation of bootstrap.sh to only occur if bootstrap.sh is present.

          2. Since I don't have php installed on my system (and it's not a build-dep), configure failed looking for "php-config". I have modified the invocation of configure to pass --without-php --without-php-extension. An alternative would be to add php as a build dependency, but that didn't seem appropriate since we aren't building a php package. It is however, entirely possible that I have misunderstood the role of php in the build, and if that is the case a build dependency would be the correct way to fix this.

          Show
          Jared Bunting added a comment - I ran into two small problems with the patch so I'm attaching my modifications. 1. I know that this patch is intended for the source tree, but when applied to the source tarball, debian/rules doesn't work due to invoking bootstrap.sh. So, I've changed the invocation of bootstrap.sh to only occur if bootstrap.sh is present. 2. Since I don't have php installed on my system (and it's not a build-dep), configure failed looking for "php-config". I have modified the invocation of configure to pass --without-php --without-php-extension. An alternative would be to add php as a build dependency, but that didn't seem appropriate since we aren't building a php package. It is however, entirely possible that I have misunderstood the role of php in the build, and if that is the case a build dependency would be the correct way to fix this.
          Hide
          Jared Bunting added a comment -

          Another issue that I ran into is due to the fact that this patch is for debian stable whereas I'm running ubuntu maverick. On maverick, python 2.4 and 2.5 are not available. Locally I have fixed this by changing XS-Python-Version from "2.4, 2.5" to "2.6" in debian/control. This obviously won't work on debian stable (as far as I know) so I didn't include it in my patch. I'd be happy to submit a correction for this, but I honestly don't know how to fix it for maverick without breaking it for stable.

          Show
          Jared Bunting added a comment - Another issue that I ran into is due to the fact that this patch is for debian stable whereas I'm running ubuntu maverick. On maverick, python 2.4 and 2.5 are not available. Locally I have fixed this by changing XS-Python-Version from "2.4, 2.5" to "2.6" in debian/control. This obviously won't work on debian stable (as far as I know) so I didn't include it in my patch. I'd be happy to submit a correction for this, but I honestly don't know how to fix it for maverick without breaking it for stable.
          Hide
          Yamashita Yuu added a comment - - edited

          added THRIFT-71_v10.patch.

          changes:

          I am managing these changes on my github page.
          https://github.com/yyuu/thrift

          Show
          Yamashita Yuu added a comment - - edited added THRIFT-71_v10.patch . changes: based on THRIFT-71_v8_0.5.0.patch skip invoking ./bootstrap.sh if not exists (same as THRIFT-71_v9.patch ) added package information for php5-thrift (from https://github.com/simplegeo/thrift ) I am managing these changes on my github page. https://github.com/yyuu/thrift
          Hide
          Yamashita Yuu added a comment - - edited

          Added THRIFT-71_v10.1.patch.

          changes:

          • added missing comma in debian/control. thanks for mikaelhg on github.
          Show
          Yamashita Yuu added a comment - - edited Added THRIFT-71_v10.1.patch . changes: added missing comma in debian/control. thanks for mikaelhg on github.
          Hide
          Yamashita Yuu added a comment - - edited

          Added THRIFT-71_v10.2.patch.

          changes:

          • Updated debian/control to detect available python version (but higher than 2.4) dynamicaly. I suppose that this is suitable especially for Ubuntu users.
          Show
          Yamashita Yuu added a comment - - edited Added THRIFT-71_v10.2.patch . changes: Updated debian/control to detect available python version (but higher than 2.4) dynamicaly. I suppose that this is suitable especially for Ubuntu users.
          Hide
          Esteve Fernandez added a comment -

          Yamashita's patch looks good to me. Thanks!

          Show
          Esteve Fernandez added a comment - Yamashita's patch looks good to me. Thanks!
          Hide
          David Reiss added a comment -

          I think you're right, the Debian packaging guide says something about it's better not having a debian directory at the top level. However, the important thing is that the debian directory should not be shipped with the release tarball, but in a separate diff.

          So does that mean we should not commit this patch? Or should we add the patch as a standalone file and commit that? Or should we do something else?

          Show
          David Reiss added a comment - I think you're right, the Debian packaging guide says something about it's better not having a debian directory at the top level. However, the important thing is that the debian directory should not be shipped with the release tarball, but in a separate diff. So does that mean we should not commit this patch? Or should we add the patch as a standalone file and commit that? Or should we do something else?
          Hide
          Roger Meier added a comment -

          What about placing the debian folder into contrib and create a simple shell script to create the packages?

          #!/bin/sh
          ln -s contrib/debian debian
          
          dpkg-buildpackage -rfakeroot -tc
          
          rm debian
          

          sh contrib/mingw-cross-compile.sh => creates windows thrift-compiler
          sh contrib/create-debian-packages.sh => creates the debian packages

          Show
          Roger Meier added a comment - What about placing the debian folder into contrib and create a simple shell script to create the packages? #!/bin/sh ln -s contrib/debian debian dpkg-buildpackage -rfakeroot -tc rm debian sh contrib/mingw-cross-compile.sh => creates windows thrift-compiler sh contrib/create-debian-packages.sh => creates the debian packages
          Hide
          David Reiss added a comment -

          That would be fine with me.

          Show
          David Reiss added a comment - That would be fine with me.
          Hide
          Esteve Fernandez added a comment -

          +1 to Roger's proposal

          Show
          Esteve Fernandez added a comment - +1 to Roger's proposal
          Hide
          Roger Meier added a comment -

          committed as proposed!
          did minor modifications on changelog, control and copyright

          Show
          Roger Meier added a comment - committed as proposed! did minor modifications on changelog, control and copyright

            People

            • Assignee:
              Roger Meier
              Reporter:
              Eric Anderson
            • Votes:
              5 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development