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

Tue Mar 24 10:45:40 EDT 2009

Thanks for your quick reply....

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
> (mac).

I've had a look at the source... And as far as I can see the
MonoDevelop.Deployment add-in already exposes an extension point called
"/MonoDevelop/DeployService/PackageBuilders" that enables new add-ins to
provide package projects, by implementing the PackageBuilder class (the
description string says IDeployHandler but it doesn't seem to exists
anymore).

But to what extend do we wish to change this? Do we need a complete
rewrite...
As doing so means adopting the Autotools add-in to a new extension point...
>From what I've seen, I'd imagine that most of the abstraction layer is
already in place... And that what's needed is changes as to how these
abstractions are exposed as UI...

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
> :-)
>
I agree, there's no limits to the things I can do... But I think I need a
limited project to apply for GSoC...
That said nobody says I need to be bound by those limits :)

But do you think the following goals would qualify as a reasonable GSoC
project?
1) Changing the MonoDevelop.Deployment add-in to facilitate "package
projects" (e.g. PackageBuilder implementations) to appear as
SolutionEntityItem, and thus removing the "PackagingProject" class.
2) Updating Autotools add-in to work with chances defined in 1.
3) Writing an add-in for creating and building debian packages using the
abstractions created in 1.

Is this too much or too little... Should I submit a proposal like this?
Anybody interested in metoring this?

--
Regards Jonas Finnemann Jensen.

On Tue, Mar 24, 2009 at 00:55, Michael Hutchinson
<m.j.hutchinson at gmail.com>wrote:

> 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
> (mac).
>
> 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
> http://mjhutchinson.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20090324/3eee49d1/attachment-0001.html 