[Discuss-gnuradio] Debian packaging

[Bdale Garbee]

I originally sent this just to Eric by accident.  Here's a copy for the
rest of the list.

Bdale

> > address@hidden (Eric Blossom) writes:
> > 
> > > I'm clueless about Debian packaging.  Could someone please explain
> > > the partioning between usrp, usrp-firmware, libusrp* and python-usrp?
> > 
> > I inherited much of the current package structuring from Ramakrishnan and
> > Steinar, who I trust will chime in if I get this wrong.  Frankly, if I were
> > starting from scratch today with the single unified release tarball, I might
> > be tempted to deliver even fewer binary packages (I already simplified from
> > what was done for the 2.7 release), but it's mostly a don't care for end 
> > users since dependencies between packages exist and "just work" in Debian.
> > 
> > The fact that the FPGA bitstrings can't be built without a non-free tool 
> > causes them to need to be in the 'contrib' tree in Debian instead of the 
> > 'main' tree as a matter of policy.  I suspect that motivated making the
> > usrp-firmware package separate.  
> > 
> > It's generally Debian policy to package shared libraries separately,
> > incorporating the soname into the package name so that when upstreams
> > go through ABI transitions we can have pre and post transition libs
> > both present on the system at the same time.  That leads to libusrp*,
> > though it's overkill as long as you continue to ignore ABI transitions
> > and assume everyone is doing coherent builds of everything from source
> > at once.
> > 
> > Debian has a fair amount of infrastructure for allowing Python modules 
> > to be packaged once and work across multiple Python versions.  Invoking
> > that infrastructure may be overkill for gnuradio today, but users generally
> > expect Python modules to have package names starting with python- .
> > 
> > The 'usrp' package picks up everything that isn't in one of the others, and
> > acts as an "anchor" through use of package dependencies for installing
> > everything necessary to have a working USRP.  It also contains stuff like
> > the hotplug goo to allow automatic firmware loading when a USRP gets plugged
> > in.
> > 
> > Prior to the 3.0 release, GNU Radio and the USRP support was structured as a
> > bunch of source packages more or less along the directory structure 
> > boundaries
> > in the current SVN repo.  With the advent of a single tarball, I've chosen 
> > to
> > restructure the Debian packaging to also have a single source package but
> > continue to deliver a number of binary packages, partly for Debian policy
> > compliance and partly because that's what existing users of Ramakrishnan and
> > Steinar's packages would expect.
> > 
> > > Also, how would I know that these correspond to the GNU Radio 3.0
> > > release?  If we make a 3.0.1 or 3.1 release, how will the
> > > corresponding packages be named?
> > 
> > Packages have a version in addition to a name.  The version has an upstream
> > part, followed by a dash and a Debian sub-revision.  The recently-uploaded
> > stuff has the version of all the binary packages built from the 'gnuradio'
> > source package set to '3.0-1', meaning it's the first Debian version based
> > on your 3.0.  If you release a 3.0.1, I'll build and upload '3.0.1-1'.  If
> > I oops and have to tweak that, I'd build and upload '3.0.1-2', and so on.
> > 
> > > Looking for a clue...
> > 
> > More clues than you probably want can be found at 
> >      
> >      http://www.debian.org/devel/
> > 
> > Note particularly the stuff on the right under 'Packaging' including the
> > Debian Policy Manual. 
> > 
> > Once my 3.0-1 packages are accepted into the mirror network, an interesting
> > place to look will be
> > 
> >       http://packages.qa.debian.org/gnuradio
> > 
> > That's not live yet because the source package named 'gnuradio' is new with 
> > my
> > restructuring for 3.0, but  you can try that with other package names to 
> > see 
> > how it works in the meantime if you'd like.
> > 
> > Bdale