Brock Pytlik wrote:
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.
There isn't anything simple to add in windows, because the drive
specifier depends on where the image is actually installed.
Keeping this with "/" at the front of paths will preserve the current
behavior. Bug 1059 can be kept open to address this in the longer term,
possibly with the second index for installpath.
Thanks.
Tom
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
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;Update Center 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
