app names cannot contain underscores

[Stuart Bishop]

snapcraft fails if snapcraft.yaml contains apps keys with underscores:

apps:
  pg_restore:
    command: pg_restore

The failure message is confusing:

Issues while validating snapcraft.yaml: The 'apps' property does not match the required schema: Additional properties are not allowed ('pg_basebackup', 'pg_dump', 'pg_restore', 'pg_dumpall', 'pg_isready' were unexpected)

Allowing underscore here is important so my commands match the extensive documentation.

[Sergio Schvezov (sergiusens)]

snapcraft abides to the design constaints in snapd

[Jamie Strandboge (jdstrand)]

FYI, many of the technical reasons why the underscore can't be used in app names these days are gone. It used to be the delimiter in the security label, but the delimiter is now '.' in series 16. The last holdout is udev TAGging still uses '_' as the delimiter (because '.' is not allowed in udev TAGs). This is needed for assigning TAGged hardware to apps within a snap.

Unfortunately udev_rules_apply_to_event() in src/udev/udev-rules.c from systemd allows only [a-zA-Z0-9_\-] so there isn't another delimiter we could use instead. It would be possible to allow '_' in the app name so long as we still disallow it in the snap name, since that would allow us to parse the TAG reliably.

[Jamie Strandboge (jdstrand)]

The review tools also abide by the design constraints of snapd, so also marking it as Opinion for now.

[Ted Gould (ted)]

On Wed, 2016-08-24 at 18:41 +0000, Jamie Strandboge wrote:
> FYI, many of the technical reasons why the underscore can't be used
> in
> app names these days are gone. It used to be the delimiter in the
> security label, but the delimiter is now '.' in series 16. The last
> holdout is udev TAGging still uses '_' as the delimiter (because '.'
> is
> not allowed in udev TAGs). This is needed for assigning TAGged
> hardware
> to apps within a snap.
We still use "_" for consistency in UAL and throughout the Unity8 stack
with both snaps and clicks. I'm honestly not sure what would break, but
I don't think it would be pretty if we allowed that in app or package
names.

[Gustavo Niemeyer (niemeyer)]

[copying the answer provided in the snapcraft@ list]

As you can imagine the problem here is namespacing. Unlike in traditional Linux distributions, the application names inside snaps are not curated to prevent conflicts, so the naming scheme we have put in place allows everybody to own the namespace under their own snaps with that scheme.

That said, we understand this is not optimal because, as you say, it breaks existing scripts. We have two alternative plans for how to sort this out, and will put one of them in place very soon.

> Additionally, I can't declare `apps:` keys with underscores in them, so some come out completely misnamed.

This is related but slightly orthogonal. We indeed restrict the charset used to name commands, both to enable predictable delimiters in some contexts, and also to make the system feel saner to the user. The vast majority of application names fit in the current constraints, so the question is whether it's best to have a consistent naming scheme for the user, or whether it's best to attempt to support more cases for the developer (underscores, uppercases, dots, ...). We don't have an answer yet.

[Jamie Strandboge (jdstrand)]

Marking as Confirmed instead of Triaged since as Gustavo said "We don't have an answer yet".

[James Henstridge (jamesh)]

One possible solution that would probably cover almost all real world cases would be to require that each section under `apps:` be unique after removing a set of objectionable characters. That should be fairly easy to check in snapcraft and verify at package installation time.

This way a "pg_restore" app could use "pgrestore" in the security label without fear of collisions.