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
[email protected]
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
_______________________________________________
Geany mailing list
[email protected]
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
