MacPorts port naming conventions

Mihai Moldovan ionic at macports.org
Sun Nov 5 08:16:53 UTC 2017


[Sorry, identity selection gone wrong, so resent.]

On 11/04/2017 06:55 PM, Craig Treleaven wrote:
>  have a couple of minor questions about port naming that are partly related to a recent ticket (55241):
> 
> 1) lowercase versus CamelCase

I don't think there's a hard policy. That's mostly left to the maintainer's
discretion.

In general, I personally like all-lowercase names better, but if a project is
using a special case (and does so consistently in an overall manner), I don't
see why the port name could not be named as such as well.

One other example of this is SIDPLAY (yes, SCREAMING HARD).

A counter-example is FFmpeg, that uses this special case as its official name,
but is most often referred to as ffmpeg.


> We seem to use CamelCase naming mostly for ports that provide software with a graphical user interface, eg AquaLess. But not exclusively (e.g. SourceKitten).   For instance, we have HandBrakeCLI and HandBrake.

There are many GUI programs that don't don't use camel case. Most GNOME software
is completely lowercase, KDE software as well. There are even examples that use
a mixture of almost-but-not-really-CamelCase, like wxMaxima.

Native OS X applications more often use a CamelCased name, probably due to the
widespread usage of CamelCase in NextStep.


> If I have a “mediainfo” port providing a CLI tool, should I use “MediaInfo-gui” or “mediainfo-gui” for the WIMP version?

A better question would be whether to split up CLI and GUI tools in the first
part or just combine them into the MediaInfo port.

We have historically chosen the latter path, with GUI components made
deactivateable via a (default-enabled) x11 variant/ (If the software uses X11 in
the first place. Otherwise, a (default-enabled) toolkit-denoting variant, like
qtX, gtkX, wx or quartz for the native OS X interface or whatever might be more
appropriate.)


> 2) libsomething versus somethinglib
> 
> I recently added the mediainfolib port and pondered whether it should be named libmediainfo.  On Repology, 14 repos use the latter, compared to 3 using "mediainfolib", even though the GitHub project is named “MediaInfoLib”.
> 
> https://repology.org/metapackages/?search=mediainfo&maintainer=&category=&inrepo=&notinrepo=&minspread=&maxspread=
> 
> Is there a consensus on either of these issues?

Also difficult to tell. We have some ports that use Xlib, whereas most software
uses libX.

A prominent example would be cracklib. Using libcrack in that case just sounds
plain weird (maybe only to me?), while cracklib is widely known as the project name.

For extra weirdness bonus points, try to refer to glib as "libg"!

MediaInfoLib might be special in the sense that while the upstream naming scheme
might pretty consistently be MediaInfoLib, their own Debian directory names
packages libmediainfo*, so they seem to at least be okay with using the (more
standard, at least under Debian and derivates) lib* naming scheme. Since a lot
of other projects take Debian as a reference, this packing scheme seems to have
gotten stuck.

Given this, it might make sense to rename our port to libmediainfo for
consistency with other packagers.

I feel like that's something of a special case, though, and can't be seen as
general naming advise.



Mihai



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 927 bytes
Desc: OpenPGP digital signature
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20171105/ee2a3ac5/attachment.sig>


More information about the macports-dev mailing list