Re: Bug#701081: debian-policy: mandate an encoding for filenames in binary packages
On Tue, Mar 05, 2013 at 10:17:58AM +0100, Thomas Preud'homme wrote:
> Le mardi 5 mars 2013 01:16:52, Bill Allombert a écrit :
> > On Tue, Mar 05, 2013 at 12:06:06AM +0000, Roger Leigh wrote:
> > > We have defaulted to UTF-8 locales for over a decade now. Unless
> > > there are compelling reasons not to use UTF-8 locales, maybe we
> > > could perhaps consider retiring them and having everything be
> > > UTF-8 by default at this point. If we do require this in
> > > userspace, then the naming restrictions could also be enforced
> > > in-kernel e.g. with create/open with O_CREAT to disallow non-UTF-8
> > > filename creation.
> >
> > My understanding is that we are supporting some character set that are
> > still not included in unicode.
>
> Forgive me if I missed something but it seems to me that even if we are
> supporting only charset included in unicode, people could have files created
> with another distribution / OS not encoded in UTF-8. So I don't think it's
> possible / desirable to deny opening UTF-8 filename in the kernel.
For opening, this is is necessary for backward compatibility. For
/creation/, we could certainly mandate UTF-8 for the addition of
new files, which is why I qualified with O_CREAT. The same would
apply for other syscalls which create file paths (e.g. mknod, mkdir,
bind). This would permit UTF-8 to be enforced going forward while
retaining a means for users to migrate broken naming to UTF-8.
Which locales don't currently have charsets mapping to Unicode?
Could we remove the non-UTF-8 locales which /do/ have complete
UTF-8 coverage and replace them with aliases? That would at least
achieve the transition for the vast majority of locales.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: