Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Pierre Neidhardt <mail@ambrevar.xyz>]

[-- Attachment #1: Type: text/plain, Size: 3923 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> If the majority of distributions decides on a poor name, we don't have
>> to repeat the same mistake ;)
>
> I agree, but there’s also a tension between that and not violating the
> “principle of least surprise”.  Sometimes the latter outweighs the
> former.

I agree and I'm pro the principle of least surprise.  I believe the full
package names do go in that direction.

>>> Those names are also used upstream in some cases: the tarball for
>>> wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
>>> project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
>>> naming guidelines say (info "(guix) Package Naming"), we should try to
>>> stick to the upstream name.
>>>
>>> Thoughts?
>>
>> I think it's important to ask "why should we name a package this way."
>> What's the rationale behind a package name?
>
> I agree with what you’re saying but (1) we’re talking about package
> name, which are different from fully spelled out “fancy names” (like
> “L’Abbaye des morts”).
>
> For package names, our policy is to follow upstream’s own package name.
> For The Battle of Westnoth, it’s “westnoth”.

Our  current policy is to follow upstream _project names_, which is often
different from the package name.

From the manual:

--8<---------------cut here---------------start------------->8---
   Both are usually the same and correspond to the lowercase conversion
of the project name chosen upstream, with underscores replaced with
hyphens.  For instance, GNUnet is available as ‘gnunet’, and SDL_net as
‘sdl-net’.
--8<---------------cut here---------------end--------------->8---

If you want to follow upstream _package_ names, then we should fix the
manual I think.

> By doing that, we make the user’s lives easier in that they may already
> be familiar with this short name.  If, instead, we try to roll our own
> that neither distros nor upstream uses, then we’re not helping people.

Isn't it the other way around?

I think that we would be rolling our own package name by using short names.

Using the official full project name is an attempt to prevent the
spreading of self-rolled names, in my opinion.

> Completion helps, I agree, but not everyone uses Helm either.  If you’re
> in Bash and type “guix package -i w<TAB>” and don’t see “westnoth”,
> you’re unhappy, and user unhappiness is bad.  :-)

But that's true the other way around too: A user could expect
"battle-for-wesnoth" and with

  guix package -i b<TAB>

and be disappointed.

I believe there is a confusion around orthogonal problems:

- Naming: it's about identifying package objects.  This is at the
  semantic level, nothing practical here.  This is user facing.

- Search / completion interface (bash completion and the like).  The
  problem is with Bash, not with names.  Bash completion equally fails
  at completing short names if the prefix is wrong (sl bring up a steam
  locomotive on some systems :p).  This is true for all sort of
  "prefix-based" completion systems.

We have ungoogled-chromium after all, not something many people on the planet
would expect!  :p
But I like it and I think it's a good name :)

> In a GUI things may be different because the package name doesn’t matter
> that much.

Bash completion is a UI ;)

The reason this whole thread started is because the original poster
failed to find some games among our package because of arguably not so
trivial names.  It has happened before that a package got packaged twice
because of different naming.  I believe we should strive at removing any
ambiguity in package names.

Our package names have the status of global
variables: they are the names which, I think, matter the most.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]