[MonoDevelop] deb/rpm package building addin as GSoC project

Michael Hutchinson m.j.hutchinson at gmail.com
Mon Mar 23 19:55:32 EDT 2009

2009/3/23 Jonas Finnemann Jensen <jopsen at gmail.com>:
> Hi,
> I've been thinking about participating in Google Summer of Code 2009, and as
> a Monodevelop user I have been missing a feature for distributable binary
> package building... So I was thinking that maybe GSoC would be a good
> opportunity for me to play with that... :)
> Anyway, Mono's StudentProject page encouraged me to discuss ideas on this
> maillinglist so here I am...
> What I would like to do is a package building addin that would allow
> users/developers to easily build deb or rpm packages. I remember the first
> time I had to build an Ubuntu package for a project of mine... And I
> remember that it took me forever to get it right... E.g. learn how to get
> the dependencies, man pages and .desktop files created and installed
> correctly.
> And it would a lot easier to push a quick beta release, if package building
> was something Monodevelop could handle.
> I think ideally it should be possible for a novice .Net developer from
> "Windows world" to build a .deb package for Ubuntu or Debian, without
> knowning anything about GNU Autotools, cdbs/debhelper or pbuilder... (Not
> knowing about GNU Autotools is already a possibility).
> While it should also be possible for more advanced users to customize
> control files etc...
> For a Debian/Ubuntu package I could imagine this integrated in monodevelop
> in two ways:
> 1) As an initial dialog for creating the /debian/ directory and a template
> for stuff within it, that'll enable building and handling dependencies for
> purely managed projects. Then projects with unmanaged dependencies would
> require some level of manual customization of the control file. Also there'd
> ofcourse need to be a simple GUI for generating the .dsc, the diff.tar.gz
> (which shouldn't contain anything) and building the binary package using
> pbuilder.
> 2) Alternately, control files etc. would be managed completely using a GUI.
> And it should not be possible for the user to manually edit control files,
> build rules etc. Thus probably setting some limits as to how complex
> projects can be packaged this way... But also making it almost trivial for
> even novice .Net developers to easily build .deb packages for fully managed
> projects.
> What do you think?
> I've searched a bit and found these wiki pages:
> http://monodevelop.com/Packaging_Projects_Overhaul
> http://monodevelop.com/Build_Service_Integration_Plans
> Now, personally, I think build service integration is mostly interesting for
> unmanaged projects that you wish to build for multiple architechtures...
> And maybe for building managed packages for SUSE on Ubuntu and likewise...
> However, in these cases developers would have to test the package on SUSE
> anyway, and thus need either a SUSE PC or VM.

This is true, but don't forget that MD can handle C/C++ code. And as
we go cross-platform, we then run into things like having to build
WiX/msi packages on Windows, dmgs on Macs, etc, so having some kinds
of remote build capability system is always useful. However, I agree
it's not a priority.

> IMO, building locally would be ideal for most users... As you shouldn't
> really ship, not even, beta releases without at least trying the package
> first :)

Definitely true.

> Having read the "Packaging Projects Overhaul" page I've gotten a bit
> confused... It says: A project should correspond to a single logical
> "package".
> Now, does that mean that packaging projects would appear as subprojects of a
> project, and wouldn't this prevent me from including multiple projects in
> the same package. Or does it just mean that a packaging project should be a
> subproject of a solution... Instead of having a "packaging project" as a
> subproject of a "package project" of a solution as is now?

The latter. The idea is that a "Package project" is a project in your
solution, that generates a package. The package project could
reference as many of the other projects in the solution as desired, in
order to include their output in the package. The project would
contain the spec files, dsc, etc. Building the project would build the
packages (and build the projects it depended on, if necessary).

> Well, I just wanted to discuss this before submitting a proposal... Also I
> have no idea, if you think this would work as GSoC project?

Yes, it would make a great project!

> And whether to make a GSoC proposal for an overhaul of the packaging
> projects or just about doing deb (and/or rpm) package building from
> Monodevelop?

It would need an overhaul either way -- this should be implemented in
a somewhat abstracted way, so that different package outputs can be
plugged into the system. For example: deb, rpm, msi (windows), app

The base abstractions and the deb backend would make a good project,
though obviously the more you do, the better. There's no end to the
things you could do -- dsc/spec wizards, GUIs for editing the package,
choosing the file layout, code complaetion for spec files, all sorts

> Also I have no idea if anybody is working on any of this? Or if it's already
> implemented (I see the wiki pages were from May 2008)?
> And if anybody would mentor this as GSoC project?

No-one's been working on this in MonoDevelop.

However, as you can guess from the second screenshot at
http://tirania.org/blog/archive/2009/Mar-10.html, there is someone
working on a similar feature for VS. It would be very useful to
coordinate and make sure that these are compatible.

> By the way, if you want to know anything about me (if you don't skip
> this).... I'm Jonas, 21 yearsold, from Denmark, Study CS at Aalborg
> University and have been writing .Net since 1.1 (way before I moved to Linux
> in 05), have also be following mono before I moved to Linux and still reads
> monologue... I am now developing mono based apps on Linux using Monodevelop.
> And have been using Monodevelop since it was almost too unstable to use :)
> (The 1.0 release I've been using lately is quite stable).
> I currently run Ubuntu, have experience packaging .deb packages for it...  A
> project of mine would be TheLastRipper
> (http://code.google.com/p/thelastripper).
> Apart from C#, I'm a little Python, C, php, javascript and the list goes
> on....

Sounds like you have the experience for this project :)

Michael Hutchinson

More information about the Monodevelop-list mailing list