Tom Mueller wrote:
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.
Well, if you can point me to a simple thing to prepend on windows
that'll work without me special casing for windows, I'll add that.
Otherwise I'm keeping the existing behavior and declaring this not this
bug(s). It's pretty clear to me that preferring /usr/bin/ls over
usr/bin/ls if those are the two choices is desirable.
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).
I would like that functionality too. Of course, it would (probably,
roughly) double the size of the index. And what should happen then on
remote search? I think instead the right answer is to strip on the
client side, but that has the conflation issues I pointed out earlier.
Not happening in this wad.
Brock
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
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
