java-gnome 4.1.3, released 4 May 2013
About
Overview, News
Documentation
Tutorials, API, and Hacking
Download
Binaries and Source
Interact
Mailing Lists, IRC, and Reporting Bugs

doc/design/3a-PackageNames

Re-engineering (3): Package names

This is a minor matter, but while we’re breaking everything anyway, several people have commented that the old java-gnome 2.x package names were really messed up.

Library names, prefixes, and suffixes

Specifically, we have glib-java, cairo-java. All good. Then we have libgtk-java. Huh? Shouldn’t that be just gtk-java? Or, alternately, the first should have been libglib-java. Tell me that doesn’t look stupid.

Personally, I’m inclined to ditch the lib prefix:

but then it gets tricky:

We already get no end of confusion with people wondering where to get “java-gnome”. More to the point, libgnome{,ui} is the thing we’re wrapping, so should it be

for instance? Same applies to Glade - libglade is the thing we’re wrapping, which would imply we keep

even though that seems stupid. On the other hand, just getting on with it, regardless of the underlying library name, seems smart:

which, incidentally, matches what the GTK# folks did, calling it glade-sharp.

That raises another point. Is the -java suffix what people want? We could as easily switch to:

etc. I’m really undecided about it. Using a suffix matches current practise and the GTK# ‘-sharp’ naming pattern to boot, whereas the prefix keeps all the libs nicely together in a directory listing (and one in the middle, java-gnome, matches our current branding).

Open to suggestions.

Of course, changing package names is hell for downstream distros doing the actual packaging, but given that there is a major API break happening concurrently, I don’t view renaming as a completely offencive thing to contemplate :)

Number of release blobs

An even bigger question is whether or not we need this many individual libraries. I for one am already sick and tired of doing releases on 8+ libraries each time a macro in the single base library changes. (Of course, that’s just the gross negligence of the GNU autotools for you. We won’t be using those in the future).

So we could well reduce it to

And be done with it. A variation on this theme is to do as pyGTK has done:

etc which is a naming split based around the constraints of what is allowed to go into the bindings set, desktop set, etc of GNOME. Looks a bit inconsistent, though.

Decision? How about just one!

Another variation is what the GTK# folks did, which is one source leads to however many packages a given distro wishes. That actually seems rather appealing, but they ran all afoul of the GNOME release team over this for some reason.

Personally, anything that lets us not have to zillions of tarballs would make me much happier, so:

Right now, the new Java bindings are just a single java-gnome and it contains everything. We’ll see how long we can keep that up, but someone is going to have to pay me a lot of money to change it.

AfC

Originally written as an email to java-gnome-hackers by Andrew Cowie on 24 Aug 06; last modified 24 Aug 07.

Contents copyright © 2006-2011 Operational Dynamics Consulting Pty Ltd, and Others. See AUTHORS file and source code history for the various files comprising this site for full details. This page was generated from a text document! We use John Gruber's Markdown syntax as ported to PHP by Michel Fortin. See MARKUP for details