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