[Lumiera] GDL question

Ichthyostega prg at ichthyostega.de
Sat Oct 15 16:03:32 CEST 2011

>> Does anyone already care for packaging?

> Don't think so.  All I could find are rpm packages as well.

>> Thus, basically we should be careful not to run into a dead end... ;-)

Am 15.10.2011 05:09, schrieb Michael Fisher:
> I agree. If major linux distros haven't picked it up yet, then it makes me
> wonder if they ever will.  This gdlmm lib has been around for a good 2 years
> if not more. I suppose the lumiera sources could house it's own copy of
> gdlmm. Not sure if that would be a good or bad idea.

well... just judging from a package description, which could be something
along the lines of "C++ bindings for Gnome Docking Library", this doesn't
sound exciting, rather boring. Something only those few percent of active
developers do care for. Developers usually don't care for packaging and
distros -- frequently they use bleeding edge and build everything from
sources anyway. So it boils down to some major or otherwise interesting
application relying on such a library -- then it will get packaged.

> Is there a 'general' procedure for getting new packages added into 
> distributions?  Or is it usually up to the community to make that happen?  I
> certainly don't want to spend a bunch of time porting the panel system to
> gdlmm just for it to get dropped and forgotten.

This happens on a per-distro base, so there is no 'general' procedure.
But every distro has its own canonical way of getting something packaged.

Personally, I mostly care for Debian and derivatives (Ubuntu...).
Here, there are several canonical (pun not really intended) paths:

1) The first-class members of the Debian "knightly order" are the
   "Debian Developers". Each of them cares for a bunch of packages.
   Thus: one option is to find a DD and get him/her interested in
   the topic.

2) Everyone can set up a Debian packaging for his toy application.
   Thus, we could approach some Debian Developer with a package
   we prepared ourselves, and ask him to "sponsor" the package.
   The DD will then review the package for policy violations
   and for relevance and then (hopefully) upload it to
   the current Debian/Unstable

3) There are some specialised Mulitmedia distributions based
   on Debian. They have special ways of proposal/collaboration,
   but the net effect is for some DD also participating in
   that special endeavour to upload the packages finally

4) Ubuntu/Canonical has also its own, more centralist mechanisms
   for proposal and inclusion. Packages from Ubuntu are usually
   easy to rebuild on Debian, and often even picked up
   by Debian proper.

For Lumiera, we're planning to take Route (2). This includes a package
for Christian's NoBug. Thus we could as well include packages for other
interesting libraries or tools we're depending on. Baseline is that we
(actually I) have to define and maintain the packages for the time being
It's a little bit of initial work (about 2 days), and from then on not
much of a burden, because in Debian packaging, everything is automated.
All you have to do is to set new release tags, add a line to the release
notes, trigger the build, then add it to the repository through a
maintenance script and rsync the change to the server.

What makes matters a little bit more involved right now is that I've
started to build also for several flavours (Debian/stable, Debian/testing,
Ubuntu/LTS, Ubuntu current and previous). I do that to get a feeling for
possible incompatibilities.  Currently, I'm using a bunch of VirtualBox
machines on my local PC. Christian indicated that he's planning to extend
his Builddrone for automating this task, probably relying on QEmu. Nontheless
this means scripting the process "packaging in VM" and it means installing
a new linux flavour from time to time. Yet still, adding one or two or
three additional packages to those tasks shouldn't be much of an issue.

So basically, all boils down to the question if we want to take the risk of
relying on another library with a very small developer base (a single dev?).
For me, in the extreme this includes the consequence of maintaining a fixed
version of that library, should the upstream developer choose to abandon it.

What do you think? Does this sound feasible?


More information about the Lumiera mailing list