Bug#757760: debian-policy: please document build profiles

[Guillem Jover <guillem@debian.org>]

Hi!

On Fri, 2025-12-05 at 13:19:40 +0100, Guillem Jover wrote:
> Unless I missed it, I don't see any definition of what is a valid
> build profile name, and that would match with the current implementation
> in dpkg, which did not either. I think this was a mistake, because
> in contrast to architecture names which get defined first in dpkg
> (although you can use anything you want but dpkg will still validate
> its format, that is alphanumeric and «-»), with build profiles, those
> get defined outside of dpkg, so there's no vetting.
> 
> As I mentioned in a recent thread in debian-devel, this has already
> caused at least two issues with colliding characters usage in different
> context.
> 
> One is with the use of «.» as namespace separator in a format where
> package names are involved, where «.» is a valid package name
> character (I still think this should be progressively be switched to
> use «/»).
> 
> The other has been in the mapping of the formulas in the Package-List
> field, where «+» is being used and is a valid package name, which
> means parsing the field is ambiguous. I've solved this now by
> deprecating the profile keyword with a new profile:v1 one.

The new profile:v1 is now part of dpkg >= 1.23.0. (Which I don't
think currently concerns Debian Policy as it does not document that
property in the field.)

> While making the parser more strict to catch invalid syntaxes, I've
> now also reduced the allowed characters for the build profiles to the
> following Perl regex:
> 
>   qr{
>     !?
>     # Be lenient for now. Accept operators for extensibility, uppercase,
>     # and package name characters.
>     [
>         ?/;:=@%*~_
>         A-Z
>         a-z0-9+.\-
>     ]+
>   }x
> 
> So, starting with an optional «!», package characters [a-z0-9+.-],
> uppercase [A-Z], and operators [?/;:=@%*~_]. But I'm considering
> reducing the last one at least to include «/» and perhaps some other
> choice characters? But I think the above regex should be the maximum
> accepted in any case.

This is now also part of dpkg >= 1.23.0, with commits:

  https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=d5ef1bfa677d37e1daa1aeb4235d18fc679a76d2
  https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=7ef1a039771fc833ca0518e50cc68c21c8c6f872

I still think it might be worth reducing the allowed characters
further, but I don't consider there's any hurry in doing that.

Thanks,
Guillem