[Bug 1086997] [NEW] apt-get fails if a package has a space in its Filename

[Daniel Hartwig]

On 6 December 2012 12:05, Thomas Bushnell, BSG
<1086997 at bugs.launchpad.net> 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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1086997

Title:
  apt-get fails if a package has a space in its Filename

Status in “apt” package in Ubuntu:
  New

Bug description:
  If a package has a space in its Filename: entry in the Packages file,
  you get errors on HTTP resolution.

  Normal Debian repos don't have a case like that, but the Packages file
  should work even if packages are not stored in the pool in the most
  usual way.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1086997/+subscriptions