No, certainly not. The details are embarrassing for a public bug so I was
being cagey. :)
I was parsing Source: lines incorrectly. The policy manual says that
version numbers on a Source line are allowed in .changes and .deb controls,
but not .dsc. This makes sense; for .debs in particular they are necessary
for binary NMUs.
But I misread that, as if the Source: line was allowed only for .changes
files. And so when I encountered a .deb that had a Source: line with a
version in it, I created a pool directory with the "wrong" name. So if
there was:
Package: foo
Version: 1.9+1
Source: foo (1.9)
I would create "pool/main/f/foo (1.9)/foo_1.9+1_amd64.deb" and create a
Filename: argument to match.
The problem with apt-get handling of this was actually a happy accident,
because it highlighted this case so I could fix it!
Thomas
On Wed, Dec 5, 2012 at 10:25 PM, Daniel Hartwig <email address hidden> wrote:
> On 6 December 2012 14:06, Thomas Bushnell BSG
> <email address hidden> wrote:
> > And in my case, there was an independent
> > bug *producing* the directories with spaces in them which I did not
> > intend.
>
> Ah, I had thought you were stuck with those directories!
>
> --
> You received this bug notification because you are a member of Goobuntu
> Team, which is subscribed to the bug report.
> 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
>
No, certainly not. The details are embarrassing for a public bug so I was
being cagey. :)
I was parsing Source: lines incorrectly. The policy manual says that
version numbers on a Source line are allowed in .changes and .deb controls,
but not .dsc. This makes sense; for .debs in particular they are necessary
for binary NMUs.
But I misread that, as if the Source: line was allowed only for .changes
files. And so when I encountered a .deb that had a Source: line with a
version in it, I created a pool directory with the "wrong" name. So if
there was:
Package: foo
Version: 1.9+1
Source: foo (1.9)
I would create "pool/main/f/foo (1.9)/foo_ 1.9+1_amd64. deb" and create a
Filename: argument to match.
The problem with apt-get handling of this was actually a happy accident,
because it highlighted this case so I could fix it!
Thomas
On Wed, Dec 5, 2012 at 10:25 PM, Daniel Hartwig <email address hidden> wrote:
> On 6 December 2012 14:06, Thomas Bushnell BSG /bugs.launchpad .net/bugs/ 1086997 /bugs.launchpad .net/ubuntu/ +source/ apt/+bug/ 1086997/ +subscriptions
> <email address hidden> wrote:
> > And in my case, there was an independent
> > bug *producing* the directories with spaces in them which I did not
> > intend.
>
> Ah, I had thought you were stuck with those directories!
>
> --
> You received this bug notification because you are a member of Goobuntu
> Team, which is subscribed to the bug report.
> https:/
>
> 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:/
>