On 6 December 2012 12:05, Thomas Bushnell, BSG
<email address hidden> wrote:
> Thanks for the reference.
Yes, who doesn't enjoy a good read of policy documents?
> I apologize for missing section D; it's not
> relevant here, but I had forgotten that it has those things. It doesn't
> actually say much relevant here.
I'd say it's still relevant:
- although not included in debian-policy, Packages is still a control file;
- section 5 defines the syntax of control files, including valid
values for a filename;
- appendix D defines the syntax of Filename fields in control files.
So yes, unless the apendices are intended to be non-normative :-)
Anyway, 5.1 does include the no-whitespace-in-filenames restriction.
Unfortunate for your situation, which would require updating
debian-policy to permit including whitespace some how. Given how many
utilities and parsers using control files there are, I don't know how
manageable such a change would be.
>
> However, I think section 5.1 is dispositive, so this isn't a bug. It's an
> unfortunate restriction, because it ends up meaning that there is no way to
> use a directory name with spaces,
>
> It's worth noting what happens when this is triggered however. It's not
> that apt-get splits it into multiple words and forgets part (which 5.1
> might suggest);
[It is appendix D that indicates a Filename /field/ is split on
whitespace. Section 5.1 only states a filename /value/ with spaces is
not allowed in control files.]
> it's that apt-get doesn't form a proper HTTP request
> because it passes the spaces through in the HTTP GET where they aren't
> allowed. Given that 5.1 says that such a Filename field is misformed, apt
> can't be blamed for failing to interpret it correctly.
Regardless of how debian-policy defines valid filenames /in control
files/, the APT Acquire system and HTTP method can be used outside the
context of debian control files, and should still issue
correctly-formed HTTP requests and save the files properly.
So I'd say that is a bug, and superficially related to bug #1003633
(although there is no requirement to percent-encode “+” in a URI).
There is a further bug here: APT is incorrectly parsing the Filename
field in Packages (according to appendix D). Filed as bug #1087129.
> I think apt-get would be very well served to escape Filename:'s when passed
> to http or https handlers, and carefully not when passed to file: handlers,
> etc. I suspect there are other bugs here which 5.1 is not relevant for,
> since it only addresses the specific case of whitespace.
Yes, I agree. And fixing the HTTP headers would probably resolve your
problem although the Packages file would still be malformed for
containing such filenames. That issue would not be fixed without a
corresponding update to debian-policy.
Anyway, I wish you well in wrestling with these server paths.
On 6 December 2012 12:05, Thomas Bushnell, BSG
<email address hidden> wrote:
> Thanks for the reference.
Yes, who doesn't enjoy a good read of policy documents?
> I apologize for missing section D; it's not
> relevant here, but I had forgotten that it has those things. It doesn't
> actually say much relevant here.
I'd say it's still relevant:
- although not included in debian-policy, Packages is still a control file;
- section 5 defines the syntax of control files, including valid
values for a filename;
- appendix D defines the syntax of Filename fields in control files.
So yes, unless the apendices are intended to be non-normative :-)
Anyway, 5.1 does include the no-whitespace- in-filenames restriction.
Unfortunate for your situation, which would require updating
debian-policy to permit including whitespace some how. Given how many
utilities and parsers using control files there are, I don't know how
manageable such a change would be.
>
> However, I think section 5.1 is dispositive, so this isn't a bug. It's an
> unfortunate restriction, because it ends up meaning that there is no way to
> use a directory name with spaces,
>
> It's worth noting what happens when this is triggered however. It's not
> that apt-get splits it into multiple words and forgets part (which 5.1
> might suggest);
[It is appendix D that indicates a Filename /field/ is split on
whitespace. Section 5.1 only states a filename /value/ with spaces is
not allowed in control files.]
> it's that apt-get doesn't form a proper HTTP request
> because it passes the spaces through in the HTTP GET where they aren't
> allowed. Given that 5.1 says that such a Filename field is misformed, apt
> can't be blamed for failing to interpret it correctly.
Regardless of how debian-policy defines valid filenames /in control
files/, the APT Acquire system and HTTP method can be used outside the
context of debian control files, and should still issue
correctly-formed HTTP requests and save the files properly.
So I'd say that is a bug, and superficially related to bug #1003633
(although there is no requirement to percent-encode “+” in a URI).
There is a further bug here: APT is incorrectly parsing the Filename
field in Packages (according to appendix D). Filed as bug #1087129.
> I think apt-get would be very well served to escape Filename:'s when passed
> to http or https handlers, and carefully not when passed to file: handlers,
> etc. I suspect there are other bugs here which 5.1 is not relevant for,
> since it only addresses the specific case of whitespace.
Yes, I agree. And fixing the HTTP headers would probably resolve your
problem although the Packages file would still be malformed for
containing such filenames. That issue would not be fixed without a
corresponding update to debian-policy.
Anyway, I wish you well in wrestling with these server paths.