#518 Confusion about '+' in a package name
Closed: Fixed None Opened 4 years ago by tibbs.

The naming guidelines are kind of confusion regarding the definitions of "separator" and "delimiter" in http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Common_Character_Set_for_Package_Naming

Basically, there's a question about the package perl-Text-Tabs+Wrap.

Is '+' a separator and therefore not allowed? Is it part of the package name and therefore allowed? How do you decide? For example, look at "tcp_wrappers". It would seem to me that the upstream name of the thing is just tcp_wrappers, but the Separators section has a special exemption section for that.

I don't know what the correct answer would be, but if there's consensus then I'll happily draft a proposal. Simplest thing would be to allow the same exception for '+' as for '_': Allow it if it's naturally part of the package name.

Of course, we don't define naturally, either. That whole thing is kind of a mess.


Traditionally, the + and . would be considered separators and therefore they'd have to be changed to dashes unless there was an exception in the separator section. I don't remember for sure why we finally settled on the wording in the Common Character Set section that includes dot and plus but then referred people to separators where they're disallowed but I do recall a lot of contention around the character set section. I have a vague, almost dreamlike (where dream I mean nightmarish) recollection of it being some kind of compromise because as a "character set" there was nothing wrong with them but we didn't actually want them to be used in the Name: field in practice.

If the current FPC agrees with disallowing dots and pluses in package names then it makes the most sense to remove the dot and plus from the Common Character Set section. (You can leave them in the separator section so that people know they need to replace them with dashes and/or in the character set section mention that most of the time other characters are replaced with dashes).

The terms "separator" and "delimiter" are used interchangeably, but delimiter is much more technical. Using synonymous words can help giving the reader a clue.

One story about '+' as a separator between name parts is that RPM defaults to '-' for all implicit separators in a "E:N-V-R.A" package file name, and also for sub-package definitions.

However, in spec files you can tell RPM the full name of a sub-package instead of just the appended name part. You could use a separator other than '-' then, and that's one reason why the guidelines ask that only '-' is to be used and not anything pretty the packager might come up with. Since '+', '_' and '.' are also allowed in Version and Release, it would only add confusion to allow those characters as separators in addition to RPM's implicit '-'.

As another story, Yum used to have problems with '+' in package names, but technically it's not a problem. There is a bunch of packages in the dist with '+' or '++' in the name or a name part, and it doesn't make a difference whether a package name part ends with '+', '++' or '+foo'.

Traditionally, the + and . would be considered separators

In version comparison, not in %name. There are a few pitfalls related to RPM version comparison and special characters, such as '+' and '_'.

[...]

For the perl-Text-Tabs+Wrap module, I don't think it's a "separator". It's really just a short form for TabsAndWrap for the Text::Tabs and Text::Wrap modules (where '::' is a separator and '-' is the separator in the project name).

The '++' in xmlrpc-c-client++ is part of the name and not two separators either.

We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-26/fpc.2015-03-26-16.00.txt):

  • 518 Confusion about '+' in a package name (geppetto, 16:46:10)

  • LINK: https://fedorahosted.org/fpc/ticket/518 (geppetto, 16:46:15)
  • ACTION: The + here isn't a delimiter, so it's fine to use
    (geppetto, 17:02:56)

Metadata Update from @james:
- Issue assigned to tibbs

2 years ago

Login to comment on this ticket.

Metadata