On Wed, Nov 22, 2017 at 2:02 AM, Michał Górny <mgo...@gentoo.org> wrote: > W dniu wto, 21.11.2017 o godzinie 20∶59 -0600, użytkownik R0b0t1 > napisał: >> On Mon, Nov 20, 2017 at 12:42 PM, Michał Górny <mgo...@gentoo.org> wrote: >> > W dniu czw, 16.11.2017 o godzinie 11∶19 +0100, użytkownik Michał Górny >> > napisał: >> > > Hi, everyone. >> > > >> > > Here's the updated version of GLEP 74 taking into consideration >> > > the points made during the Council pre-review. >> > > >> > > ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst >> > > HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html >> > > >> > >> > New changes: >> > >> > 9d819c9 glep-0074: Disallow filenames containing whitespace >> >> This seems like a bad idea. I apologize if this is covered in more >> detail somewhere, but the only justification I can see is that the >> current grammar does not permit quoting or some other method of >> specifying whitespace as part of a field value. >> >> Is there any way to assure that this won't break things in a >> non-obvious way? I'm having a hard time imagining how it would be an >> inflexible requirement to use a space in a filename, but it could come >> up if it was necessary to use Portage on a non-Gentoo distribution. > > Having a whitespace there *will* break the parser. Until a better parser > is provided, we need to reject it to prevent tools from accidentally > generating broken files. It's better to tell straight away 'sorry, you > can't use Manifest here' than cause completely unexpected behavior > in the parser. > > Using whitespace in filenames is going to break Portage in horrible > ways. Half of shell script in it is based on whitespace-separated lists. > PMS doesn't provide any means to replace some of them. It's not going to > happen. >
Yes, I was talking about providing a better parser. I understand it is as it is now because whitespace is a delimiter. If it's not possible to know where all code that has this as a requirement is, that's fairly bad. http://langsec.org/occupy/ >> It seems very arbitrary. I think the better solution is to use a better >> parser. >> > > The parser is already there for 15 years or more. We can't just replace > it without breaking all old Portage versions. > It sounds like portage is already broken. Cheers, R0b0t1
