Brock,
IMO, the code in file.py should not use os.path.sep when constructing
the value for the "path" tag that is going to be indexed. The reason is
that "path" values always use "/", even when publishing a Windows
package. The standardized form of the value for pkg(5) is to use "/" for
the separator. It is converted to an OS-specific path only when it is
prepended with the image root and converted into a file path. Anytime
the path tag for an action is manipulated without it representing a
complete pathname, it should have slashes ("/").
If something is going to prepended to the front to represent the image
root for the system image, "os.path.sep" is not the thing to prepend on
Windows because this misses the drive part of the path.
For Windows, I'd still like to see the solution where we have two values
indexed for each file: the "path" which is the value from the action,
without the leading "/" and an "installpath" which is the location where
the file is installed for that image. That way either type of search
("bin/ant" or "bin\ant" or "C:\myimage\bin\ant") would work. This
solution would be useful on all platforms and for user images as well.
However, the problem of images being mounted at multiple locations would
need to be handled (for the system image too).
Thanks.
Tom
Brock Pytlik wrote:
Danek Duvall wrote:
On Mon, Mar 09, 2009 at 08:14:23PM -0700, Brock Pytlik wrote:
I'll be honest, I don't know what the right solution is here. For
this put back, I think mimicking existing behavior is an adequate goal.
Stepping back for a larger picture, I'm not sure what the final goal
is. searching for `whence ls` is nice idea in theory, but has some
large problems. [ ... ]
Yup, which is why I'd started to put down "you should fix 1059 while
you're
here" and then thought about it long enough to realize that wasn't
fair. I
just brought it up here because it was similarly not clear whether
sticking
with "/" or using os.path.sep would be better, and wanted to be sure you
thought the issue through before committing to the switch.
Danek
I will give it some thought. Part of the problem is that the
interaction between category hierarchies and file paths could be
troubling. Suppose there's a category of /fun/games, and a user
creates a user image in /fun. If they do a search for /fun/games, are
they looking for things in the /fun/games directiory (in which case I
should strip the leading /fun) or are they looking for things with the
/fun/games category. Since we have OR now, it's possible to search for
both, but with wildcarding, we could easily end up duplicating
results. The question for me for this putback is whether we want
/usr/bin/ls or usr/bin/ls to match, since we can only have one (for
now, at least that I can think of at the moment). I lean towards
having the former work, which then means what do we want to do on
windows. Should they search for \usr/bin/ls or /usr/bin/ls, and
regardless of OS, are any of those sane choices for items installed in
user images.
I've CC'd Tom to get his thoughts on what behavior is desired on Windows.
In general, we've been optimizing for the system/root image, and I
think that's still the right choice to make for now.
Brock
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;SWI Install/Update Software
adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA
email;internet:[email protected]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-916-9943
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
