On 12/18/2011 05:26 AM, Dominic Hopf wrote:
Am Samstag, den 17.12.2011, 21:27 -0800 schrieb Matthew Brush:
Here's a reasonable list of packages that could exist:
geany<- core application geany-common<- ? geany-dev<- geany.pc and header files geany-extras<- geany themes, bindings, tags geany-vala<- vala binding geany-python<- python binding geany-themes<- all theme files from geany-themes geany-tags<- all geany tags (slooooooow!) geany-tags-c<- C tags only geany-tags-python<- Python tags only, and so on... ...other tags geany-plugins<- all plugins combined geany-plugins-common<- ? geany-plugin-addons<- Addon plugin only, and so on... ...other plugins
I'd basically say we shouldn't even care about the packages of specific GNU/Linux distributions upstream and leave the packaging up to the particular package maintainer. They have to find the right way for their users to provide as much flexibility as possible for the user when installing stuff and keeping package maintenance efforts feasible for them.
Yeah, I just meant it to provide some ideas because there's some new stuff that isn't currently packaged.
While we're at it and I'm maintaining some stuff on Fedora I can tell you my personal opinion: I'd put everything I find as a separate repository upstream [1] in a separate package. In case some packages are too big or it would make sense, I'd maybe split a package into sub-packages.
Note the technical difference between separate packages and sub-packages as it is the case for example for the geany-plugins-* stuff in Fedora: geany-plugins is another package than geany, but geany-plugins-$foo is a sub-package of geany-plugins. There is no installable so-called meta-package called "geany-plugins" which would install every plugin, users would just type `yum install geany-plugins-*` to install everything.
I didn't know about this, I've only ever made Debian packages, and even that was just for my own use :)
The situation for Tag files taken from [2] is a bit special, because they currently are just additional sources for the Geany package in Fedora and thus installed when you do a `yum install geany`. Users did not claim yet about a bloated package, they rather provided feedback that they found this a cool feature. I don't see a reason (yet) why I should put every tag file in a separate sub-package. I can imagine a separate package for geany-tags, though. This however will be not easy to change, since removing the tags files from the Geany package (they were there since Geany is in Fedora) would significantly change the behavior of Geany in Fedora and thus maybe only can be done between different Fedora releases.
The problem is that your source [2] isn't where the tags are anymore, they're all moved to the Wiki and there's lots of new ones as well. The reason you might want separately packages for different tag file languages is that Geany becomes terribly slow as you add more tags for a given language. If you have too many tag files, when you a load a file that uses the language of those tags, Geany freezes for a noticeable amount of time while it parses the tag files.
To get back to the topic: A geany-themes package would be easily possible, not sure yet about the way to package - separate package or sub-package of geany, but this mainly is a question of package maintenance in Fedora and the difference will not be even obvious for the user. I tend to put it in a newly created separate package since the themes are (or will/would be) provided in a separate repository upstream and extending the Geany package itself in that amount would need a re-review for the Geany package in Fedora.
I don't know about this, but finally we're getting to my original question, "can someone make packages for geany-themes" :) So is this something you wouldn't mind doing for Fedora?
Did I miss something for the Python and Vala stuff (are they there yet?) or was this just example names? :)
The Vala binding is two files (geany.vapi and geany.deps) which need to go into the system's VAPI dir (it's /usr/share/vala-VERSION/vapi here). This allows to write plugins in Vala, and at present the one plugin (which I just added) that uses the binding embeds these files in the source, but as soon as one more Vala plugin comes along, it will be weird having the Vala binding embedded twice in two different places, which is why I suggested a package for it. IIUC, the Vala files would typically be installed with the -dev package (on Debian), along with the pkg-config file and headers.
I'm not too sure about how GeanyPy should be packaged. It provides two things; a Python binding and a Geany-Plugin. Typically in Debian, the binding would be a package called `python-geany` but since the actual Geany-Plugin for GeanyPy can't work without the Python binding and the Python binding can't work without GeanyPy, it might not make much sense to split it up. Probably best here is just to have it be a regular plugin with both parts in it.
Cheers, Matthew Brush
Regards, Dominic
[1] https://github.com/geany [2] http://download.geany.org/contrib/tags/
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany