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

[Jonas Finnemann Jensen]

Hi,

I've thought about a few things and added a great deal of details... The
results indeed very much inspired by the packaging project proposal on the
MonoDevelop wiki...

I've submitted it, and it can be found here:
http://socghop.appspot.com/student_proposal/show/google/gsoc2009/jopsen/t123858633526
or as pdf here:
http://jopsen.dk/downloads/GSoC_Packaging_proposal_for_MonoDevelop.pdf

Just thought I'd let you know... :)

--
Regards Jonas Finnemann Jensen.


On Sat, Mar 28, 2009 at 08:14, Michael Hutchinson
<m.j.hutchinson at gmail.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20090401/d58a013c/attachment.html