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

[Michael Hutchinson]

On Tue, Mar 24, 2009 at 7:45 AM, Jonas Finnemann Jensen
<jopsen at gmail.com> wrote:
> 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).

Yes, there's an existing deployment addin which has a good usable
core, but I believe that the user-visaible project model is currently
somewhat broken.

> 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...

Yes, the changes I envisage are for the UI, and extensions to build
rpm/deb/etc packages. The existing core is sound.

>> 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?

That sounds to me like a good project. I'd like to see more details,
especially of the abstractions and UI behind the debian packaging (it
would be very useful if it's trivial to add an rpm addin). It would
also be interesting to have some  "stretch goals" -- things you'd do
if you have time, but which aren't required for a successful final
evaluation. I'd be willng to mentor it.

-- 
Michael Hutchinson
http://mjhutchinson.com