Right now, repoman disallows files with '@' [at] character in their names. Such a filenames are used by some systemd units, thus it would be great if that character was allowed. I don't see anything in PMS limiting the characters in AUX files, thus assigning this to qa@.
I guess the question would be if all the filesystems support properly filenames with that character. Given that we have Gentoo/Alt, NTFS and FAT might be a concern.
at least on interix (NTFS), touch "abc@def" works as expected. however i find it very questionable to allow such filenames. IMHO problems on other filesystems, or in strange combinations with some third party portage-tree-crawlers (or whatever) are pre-programmed...
The @ sign is not in the ISO_646.basic:1983 charset, so there might be potential encoding issues. I'd rather avoid such unsafe characters in filenames.
In any case, systemd requires packages to use that character in some unit names. IOW, the packages are going to install such files into the filesystem anyway. The question is whether we'll just keep them like that in ${FILESDIR} or rename during install.
HFS+ has no problem with it either, but I agree with the feeling it is ugly. I think NFS, AFS and Samba/CIFS should be safe regarding the @ too since they usually rely on the underlying filesystem.
Windows explicitly allows filenames containing "@" via the Win32 API, so FAT and NTFS are not an issue.
although it seem like not beeing an issue regarding filesystems, i have a strong vote against keeping those files with that name in the tree. rather rename them on installing.
(In reply to comment #4) installing the package is different from syncing the portage tree. you're free to install those files with those chars, but not store than with those chars in the portage tree. the filename requirements for the portage tree are much more strict than the install step. i dont see anyone in favor of this, and it isnt that big of a hassle to require you to use `newins` rather than `doins`, so close it out.
