Tcl packaging guidelines

[Michael Thomas]

Toshio Kuratomi wrote:
> '''
> == Naming Conventions ==
> 
> It is common for Tcl applications and extensions to begin with a 'tcl'
> or 'tk' prefix in the upstream name.  Fedora Tcl packages should follow
> this convention.  If the upstream name does not contain the 'tcl' or
> 'tk' prefix, then it is only necessary to add one if the upstream name
> is inappropriately generic.  For example, the 'thread' extension to Tcl
> is named 'thread' upstream, but is named 'tclthread' in Fedora.  The
> upstream name for the 'bwidget' extension is uncommon enough that it
> does not need to contain the 'tcl' or 'tk' prefix in the Fedora package
> name.
> '''
> 
> * Other languages use $LANGUAGE-$MODULE naming.
> * All modules in perl, ruby, and php are using the $LANGUAGE- prefix,
> there has been talk of removing the python exception (ie: having
> python-pygpgme instead of pygpgme) as having all modules use
> $LANGUAGE-$MODULE makes it easier for endusers to find modules written
> for the language they are writing their program in.
> 
> So I'd propose:
> * For modules, tcl-thread and tcl-bwidget.  Possibly tcl-tk but someone
> with more experience with tcl/tk will have to tell me if that makes
> sense.

I would consider Tk a special case, and that the guidelines should allow 
for either the 'tcl' or 'tk' prefix to be used.

Would you agree that if upstream uses a name prefixed by 'tcl' already, 
that we don't need to change it to a 'tcl-' prefix?  For example, we 
currently have 'tclxml'.  I argue that we don't need to change this to 
'tcl-xml', or 'tcl-tclxml', but could add an additional 'Provides: 
tcl-xml' and/or 'Provides: tcl-tclxml' if necessary.

> Applications do not need to have the language prefix as users of the
> application do not need to know what language it is written in.

+1

I'll clarify some of this in the proposal.

--Wart