[wx-dev] RFD: Debian packages for wx 3.0

[Robin Dunn]

Vadim Zeitlin wrote:
> Luckily,
> Devid Filoni, one of wx maintainers for Ubuntu, is ready to help us with
> this rewrite (thanks in advance Devid!).

Welcome and thanks from me too!  I wish I had more time to devote to
packaging, but it just simply isn't there for me.


>  The first and most important thing I'd like to change is to split wx and
> wxPython packages generation. This will, of course, need Robin's approval
> (for which I'm waiting eagerly :-) but it really doesn't make much sense to
> always build wxPython and wx packages by default and have a separate hack
> to build just the C++ packages as we do now. Logically, the packages are
> independent and wxPython ones should simply depend on the C++ ones. And
> while it probably doesn't matter much from practical point of view because
> the existing Debian maintainer will block any development anyhow, I should
> also mention that I was asked to split these packages by several people
> from Debian. I hope this can be accepted and so I'll only speak about the
> C++ packages below and will leave the specification of what wxPython
> packages we should have (possibly the same as now, of course) to Robin.

There are some advantages to keeping them together, mainly related to
being able to do coordinated sub-release releases (i.e. the 4th digit in
the version numbers, 2.8.7.1, 2.8.7.2, etc.) between the official
wxWidgets releases.  This lets me release wxPython builds in a more
timely manner that may require fixes in wxWidgets that haven't been
released yet.  Of course this can still be done however with the package
generation for wxWidgets and wxPython split, it would just be a little
easier with them combined.

So while I won't oppose the split, I'm not sure yet if I can give it a
full vote until I think more about it or see some more concrete plans.
So call it a +0.5 for now, as long as it is still easy to roll out
incremental subrelease snapshots of wxGTK as needed for wxPython releases.

BTW, not as justification or anything, just FYI, last I checked several
of the RPM based distros have started doing combined wxGTK and wxPython
builds from a single .spec file and using the tarball I produce as part
of wxPython releases.


>  Second potentially controversial proposal is to separate libwxmsw packages
> from libwxgtk ones too. Of course, libwxmsw packages may be useful but I'm
> not sure if they're useful enough for us to maintain them and if we do have
> the resources to do it I'd rather have a generic debian/rules which can
> deal with any port (GTK, X11, DFB and, well, MSW) than lumping them
> together with GTK packages arbitrarily. But for now we could start with
> having a simple and clean debian/rules for just wxGTK and generalize this
> later. What do you think?

+1

Ever since I've been running my own apt repository I've never built the
msw packages, and I've never had a request for them neither.


>  Next question is about the granularity of the libraries packages. We can
> have:
> 
> a) A single libwxgtk package including all wxGTK and wxBase libraries
> b) Separate libwxgtk and libwxbase packages just as now
> c) Multiple libwxgtk-{core,adv,html,aui,...} and libwxbase packages
> 
> I find the solution (c) to be rather attractive because it's internally
> consistent (e.g. it treats libwxbase in the same way as all the other
> libraries) and also would allow us to introduce dependencies for only some
> packages, e.g. libwxgtk-html could, in theory, depend on Gecko while still
> allowing installing all the other libraries without Gecko dependency (a
> more realistic example would probably be some dependency of libwxgtk-media).
> It also makes adding new libraries somewhat simpler.
> 
>  OTOH I don't know if it's worth the extra trouble, especially if we need
> to provide -dev and/or -dbg versions for every library. What do you think?


Another thing to think about for (c) is the packages that use wx.  With
(c) they would then have to get much more detailed in listing their
dependencies and it's easily possible that many would either not get it
right, or they would just include all the libs even if they are not
using all of them.


>  Speaking of -dbg packages, I think the plan is to make wx builds with and
> without __WXDEBUG__ ABI-compatible in wx3. If we do this, I think we should
> build wx with -O (and without -g?) but with __WXDEBUG__ defined by default.

++1

For the other platforms I already use --enable-optimise and
--enable-debug_flag (and the equivalent on MSW) in order to keep the
wxASSERTs and etc. because they are turned into Python exceptions in
wxPython.  Currently the debian/ubuntu packages do not do this and so
developers have to install the -dbg packages to get the same level of
runtime protection that the other platforms get by default.


> This would hopefully make it unnecessary to provide separate -dbg packages
> for each library although it would still be nice to have debug symbols in a
> separate package (hmm, this means building with -g though). 

IIRC you can build with -g, make the debug symbols package, and then
strip the binaries before making the lib packages.


>  The most complicated question is one of libwx-dev package(s). Currently we
> have libwxbase-dev and libwxgtk-dev. We clearly don't want to have
> libwxgtk-{core,adv,html,...}-dev so this is not really compatible with the
> proposal (c) above. But in fact I don't even like the current separation
> between libwxbase-dev and libwxgtk-dev. The -dev packages don't contain
> much, in fact: just the (build-specific) wx-config and setup.h and the .so
> link. So I'd like to propose to have the libwx-headers package (the name
> seems better/more consistent with other libraries than the current
> wx-headers) and one and only one libwx-dev package which would contain
> wx-config which could be used for both base and GUI applications
> development (using "wx-config --libs base" for the former) as well as the
> current contents of wx-common, i.e. wxrc and wxwin.m4 (having a separate
> package just for this is really not worth it IMO). What do you think of
> this approach?

+1


>  To summarize, I propose to have the following packages (not counting
> wxPython ones, again, I hope Robin can post what he'd like to do with them,
> even if it's just to say that current packages are fine and should be kept
> without changes):

Yes, as far as I know the current set of wxPython packages is fine,
although we'll want to drop the addons package in 2.9 since the need for
that one is going away.  The only issue for me at the moment is the
question of whether or not to split the generation of wxPython packages
out of wxGTK's build scripts, and I won't oppose that if that is what is
decided.



> 
> 1. Library packages:
>  - libwxbase3.0 and libwxbase-{net,xml}3.0
>  - libwxgtk-{adv,aui,core,gl,html,media,qa,richtext,src,xrc}3.0
> 
> 2. A single debug package libwx3.0-dbg containing symbols for all of the
>    above.

Do the -dbg packages need to have dependencies on the lib packages?
IOW, will installing libwx3.0-dbg force the installation of all the
libwx* packages?


> 
> 3. Development packages:
>  - libwx3.0-headers containing all headers (excluding setup.h)
>  - libwx3.0-dev containing wx-config, wxrc and setup.h

Is there any need/desire to have an additional dev package containing
the static libraries?



-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!