On Sun, May 01, 2011 at 11:15:15PM -0400, James Vega wrote:
> On Wed, Apr 20, 2011 at 04:04:31PM +0200, Adam Borowski wrote:
> > the problem is caused by the following part in /usr/bin/dget:
> > 
> >     if ($url =~ m!^(file|copy)://(/.+)!) {
> >         if ($1 eq "copy" or not link($2, $file)) {
> >             system "cp -a $2 $file";
> >             return $? >> 8;
> >         }
> >         return;
> >     }
> > 
> > Hardlinking a symlink of course doesn't update its destination.
> > 
> > There are four bugs there:
> > 1. (/.+) should be (.+) -- there's no reason relative urls shouldn't work
> 
> Relative URLs don't make much sense in a sources.list file.  What would
> they be relative to?

dget can operate on URLs provided directly.  In fact, I didn't even know of
its second mode of operation, synonymous with "apt-get source".

Relative urls make little sense for http:, but for file:, they can be
potentially useful.

[Unrelated wishlist: support for ssh:// URLs could be nice, I found myself
trying to use that on several occasions..]

> However, the file URI example in sources.list(5) suggests the format is
> "file:/absolute/path/to/file" instead of the usual
> "file://relative/path" or "file:///absolute/path".

Looking around, I see that the scheme is defined in RFC 3986:

#     URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
#
#     hier-part   = "//" authority path-abempty
#                 / path-absolute
#                 / path-rootless
#                 / path-empty
#
#  The scheme and path components are required, though the path may be
#  empty (no characters).  When authority is present, the path must
#  either be empty or begin with a slash ("/") character.  When
#  authority is not present, the path cannot begin with two slash
#  characters ("//").

The "authority" part doesn't generally make sense in file: URLs on Unix
systems (but does on Windows for SMB paths).

If I understand the RFC correctly, "file://relative/path" is _not_ correct. 
It would mean the word "relative" is an "authority" rather than a part of
the path.

Thus, the following URLs are correct:
  file:///home/kilobyte/foo/bar.dsc
  file:/home/kilobyte/foo/bar.dsc
  file:foo/bar.dsc (if cwd is ~)
but anything with exactly two slashes after colon is not (outside of Windows
and some exotic systems).


Fortunately, on regular Unices multiple slashes never hurt, so you might
just use file:(.+) -- heck, it would work as expected even on Windows.

Thus, reading the RFC I suggest changing the line:
  if ($url =~ m!^(file|copy)://(/.+)!) {
to:
  if ($url =~ m!^(file|copy):(.+)!) {


Of course, this is assuming I read this correctly...

-- 
1KB             // Microsoft corollary to Hanlon's razor:
                //      Never attribute to stupidity what can be
                //      adequately explained by malice.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to