[zeromq-dev] Debian packaging: current status & where to go from there

[Martin Sustrik]

Hi Adrian,

Quite a lot of stuff here. It'll take a while to answer...

But first of all, thanks for the packaging!

> After the various discussions (thanks a lot for your input, all!):
> 
>  * Debian package currently takes place in my Mercurial tree at 
> <https://fortytwo.ch/hg/pkg-zeromq>
>  * The package is built from the 2.0beta2 tarball.  I plan to stick to 
> tarball releases whenever possible.

Ack.

>  * The package, only C/C++ bindings for now, has been uploaded and will new 
> be reviewed by ftpmasters in due time.
>  * In the mean time, you can look at http://fortytwo.ch/debian/zeromq/
> 
> Since I started packaging without noticing the existing work from Peter 
> (which was not yet included in the beta2 tarball), it doesn't make sense to 
> try to merge (in the vcs sense) the packaging.  I took most of the 
> description from Peter because it is quite a bit better than what I had, and 
> his work still helped me getting my packaging into shape.
> 
> Now, where to go from here:
> 
>  * ship example code and perf stuff with the -dev package as sugggested.

The discussion seem to have ended with "nobody wants local_lat in 
/usr/bin". So, presumably, no packaging of perf tests at the moment.

>  * enable language bindings, probably one by one.
>    (It is quite important that the linking issues are fixed; not only is the 
> python library not linked with -lpython2.5 as I mentioned previously, but at 
> least the java JNI library ends up being linked with -lruby1.8, which 
> probably is not what is intended.  I'm absolutely not an autoconf/make guru, 
> though.)
> 
>  * Of course, if you're faster with splitting of language bindings into 
> their own packages than I am with packaging them, it gets easier for me.  
> Right now, I don't plan to package seperately released languages.

Being in your place I would rather go on with C/C++ package. Language 
bindings are tricky and we should rather depend on people who are 
actually using the language to create packages for binding.

Peter, would it make sense to try to create a CL package dependent on 
the C/C++ package? I won't be of much help here, but if you two are able 
to arrange that, it would be great.

>  * As discussed it makes sense to integrate the debian/ directory into the 
> upstream sources (I can still ship a modified package after all.)  As long 
> as I don't have any language bindings enabled (Peter's work had working 
> packages at least for CL), I guess we should postpone that (but this is 
> ultimately not my decision; for me, it's ok for you to grab "my" debian/ 
> directory as soon as you want.)

Please, Adrian, Peter, Mato, can you make a decision on how to manage 
this properly?

>  * not directly dependent, but it would be convenient ... yes, I plan to 
> learn git at some time.  Shouldn't be that hard, coming from hg.  Just not 
> in the next few days, so expect the hg based tree to stick around for a 
> while.  If you decide to ship my packaging, I will (try to remember to) send 
> my changes for inclusion, too.
> 
> Ok, so long.
> 
> cheers
> -- vbi
> 
> P.S.: listmasters: is this list half-broken?  I seem to get only part of the 
> mail, especially I think I didn't get some of the messages from our 
> packaging discussions through the list; I did only get them as cc:s.  I 
> don't remember installing duplication-removal software at my end.

I've forwarded the complaint.

Martin