Hey,
I created a package for Gnome Do plugins this morning. I already filed a review request (see https://bugzilla.redhat.com/show_bug.cgi?id=489014 ) but I expect some work to be left. Some on which I want to hear you opinions are below:
* First I created it as a noarch package. All data are under /usr/share and it's only CIL code so I expect this to be OK. Comments?
* Currently it's only one big package. In my opinion it would be good to split it into several subpackages (at least -offical and -unofficial).
* When I tried all new plugins were auto-activated. I think this is a bad behavior and we should try to auto-disable them after installing.
* It took some time but finally I got all BuildRequires. However I'm unsure how we should handle Requires. Every plugin needs other applications installed. Any ideas on this?
Besides this it would be great if anyone have some time to look at the package.
Paul
2009/3/6 Paul Lange
I created a package for Gnome Do plugins this morning. I already filed a review request (see https://bugzilla.redhat.com/show_bug.cgi?id=489014 ) but I expect some work to be left. Some on which I want to hear you opinions are below:
- First I created it as a noarch package. All data are under /usr/share
and it's only CIL code so I expect this to be OK. Comments?
Till now, I was using the DLLs extracted from the Ubuntu package with no problem.
- Currently it's only one big package. In my opinion it would be good to
split it into several subpackages (at least -offical and -unofficial).
I prefer at least two packages, as you say.
- It took some time but finally I got all BuildRequires. However I'm
unsure how we should handle Requires. Every plugin needs other applications installed. Any ideas on this?
That's the big problem. For example, the official plugins include a Rhythmbox plugin, but I don't use that app, and I will have to install it to install de plugins package :( And so on.
Well, perhaps the package should be splitted for the plugins that require a new app, like the Beagle packages. In the official plugins we have plugins for Evolution, Banshee, Firefox, Pidgin, Rhythmbox, Tomboy and Vinagre. Ufff.
The other option is create the package but with no requirements for those packages. When Gnome-Do starts, if doesn't find one package, doesn't start the plugin and everything is fine.
2009/3/6 Paul Lange palango@gmx.de
Hey,
I created a package for Gnome Do plugins this morning. I already filed a review request (see https://bugzilla.redhat.com/show_bug.cgi?id=489014 ) but I expect some work to be left. Some on which I want to hear you opinions are below:
- First I created it as a noarch package. All data are under /usr/share
and it's only CIL code so I expect this to be OK. Comments?
Against the guidelines, idiotic but true. Till such a time as we have a new set of guidelines all Mono packages should be arch. This is why I put creating new guidelines on top of the to do list
* Currently it's only one big package. In my opinion it would be good to
split it into several subpackages (at least -offical and -unofficial).
I would prefer somerthing akin to separation down to an application level. gnome-do-plugins-evolution etc. It would make the spec a tad big but it would give us good control and allow our users to select only the functionality they desire.
- When I tried all new plugins were auto-activated. I think this is a
bad behavior and we should try to auto-disable them after installing.
If you do the above then this is not a problem, people would install what they want, thus expect it to be enabled. Genius in it's simplicity really.
- It took some time but finally I got all BuildRequires. However I'm
unsure how we should handle Requires. Every plugin needs other applications installed. Any ideas on this?
rpm should pull in the requires but if you separate out the plugins then adding the required Requires to the sub packages should be pretty easy provided these aren't pulled in automagically.
Besides this it would be great if anyone have some time to look at the
package.
I have started the review, but as I am no longer a Fedora developer I can't actually approve the package. Consider it a service to the actual reviewer which should reduce his workload to being a yes man.
- David
mono@lists.stg.fedoraproject.org