Package name specification needs refinement

[mwoehlke]

Right now, the specification says that "package [...] names may consist of ASCII letters, numbers, hyphens (-), and underscores (_), and may not contain forward-stroke (/) or at-sign (@)." This is both too restrictive and too liberal; we should probably also explicitly exclude all characters not allowed in FAT file names (<, >, :, ", \, |, ?, *), and we should add + and . to the set of officially blessed characters, as these are used in existing package names. (As a bonus, this also makes the naming schema nearly identical to what CMake considers acceptable target names.)

[bruxisma]

When you say package name do you mean the canonical name (e.g., my.library) do you mean package filename? I am also unaware of any filesystem that does not currently allow the @ sign, build systems like meson do use it last I checked for hash info (e.g., target@some-hash).

[mwoehlke]

When you say package name do you mean the canonical name (e.g., my.library) [or] do you mean package filename?

Both? The only allowed difference between the package name and the CPS file name is that the latter can be lower-cased relative to the canonical spelling of the package name. (Possibly this could be relaxed a bit, in case of extremely restrictive file systems, but right now I'm not aware of any need to do so. Also, technically, things get weird on case-insensitive file systems since I believe FOO.cps will be found if looking for Foo, but I consider that UB. Practically speaking, having names that differ only by case won't end well.)

I am also unaware of any filesystem that does not currently allow the @ sign

...which is fortunate because CPS file names may contain @. It's not allowed in package names, however, as it is reserved for the configuration specifier.

Would "hash information" show up in consumer-visible names? I would think "no"...

[mwoehlke]

Note: There exist .pc files that use all of _, -, . and +. There also exist CMake packages that use -. One additional rationale for supporting additional characters is so that existing packages can "recycle" the name they already use. (This might be especially relevant if primarily-CPS ecosystems need to be able to express dependencies on things that only ship .pc files.)

[bruxisma]

Would "hash information" show up in consumer-visible names? I would think "no"...

It shows up for docker images and other OCI based artifacts that allow pinning to a particular hash/instance (separate from the version).