RFC: Naming guidelines for packages extending GIMP

[Nils Philippsen]

On Thu, 2007-09-06 at 03:16 +0100, Ewan Mac Mahon wrote:
> On Wed, Sep 05, 2007 at 11:28:50AM +0200, Nils Philippsen wrote:
> > during the review of the resynthesizer plugin for GIMP
> > [ https://bugzilla.redhat.com/show_bug.cgi?id=250210 ], I asked the
> > package to be named "gimp-plugin-resynthesizer" rather than
> > "gimp-resynthesizer". Ewan brought up the point that there isn't really
> > a naming guideline for it, therefore I'd like to propose one:
> > 
> The name gimp-resynthesizer was chosen by applying the generic case of
> the package naming guidelines which cover anything that's not special
> cased.

That's what I meant (should have been "... there isn't a special naming
guideline for it.").

> > If a package provides several distinct features that have value of their
> > own (use your own discretion on that), it must ship them as separate
> > subpackages. In that case, the source package is named
> > "gimp-extension-<collectionname>" where <collectionname> is a sensible
> > name for the collection (see examples).
> > 
> > That's all of the different kinds of extensions for GIMP I can think
> > about right now, feel free to add to the list ;-). For packages that
> > contain e.g. a plugin and some brushes, I would separate them into
> > subpackages if it is sensible to do so. If not, I would name the package
> > after the main feature (in this case, likely "gimp-plugin-..."
> 
> I think there are two related problems with this approach; from a user's
> perspective it's useful to know that a package is a gimp addon, but not
> all that useful to know whether it is implemented using a plugin, a
> script, brushes, or some combination of them. From a developers point of
> view it creates situations where it's not entirely clear how a package
> containing several different components should be named, or whether a
> package containing several components designed to be used together, but
> potentially useful apart should be split or not. There's also the
> potential to create inconsistency as people decide differently.
> 
> Essentially the package name is too short to accurately describe the
> range of possibilities, so the best approach is to not try, and mislead,
> but to simply leave it as 'gimp-addon' and put the details in the
> description field.

Hmm. I like to keep things nice and tidy and it seems that I've got a
serious crush on namespaces ;-).

> > Please comment.
> > 
> > Ewan also expressed concern about the proliferation of package
> > specific naming guidelines. Tell me what you think about that as well.
> >
> In general I think the existing naming guidelines for addons work pretty
> well, and it's only worth making an exception if there's a really good
> case, such as pre-existing convention (e.g. CPAN naming for perl
> modules), or where a single 'parent' has so many addons that it's useful
> to classify them. I don't think either of those things are the case
> here.

Not yet maybe, but there is a huge number of 3rd party GIMP plugins out
there that could be packaged.

> Short version: I don't think this is a terrible idea, I do think it's
> somewhat overkill, and on balance the downsides outweigh the upsides.

I'd say unless someone else provides some arguments beyond what I said
pro "namespacing" I'd give in to stay with just "gimp-<something>" but I
reserve bringing this issue up again if we at some point in the future
have a huge number of plugins. Sounds okay?

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011