Tom Mueller (pkg-discuss) wrote: > The package display menu assumes that packages are put into the > repository with a common release/branch value indicating a set of > packages that go together. While this happens to be true for > OpenSolaris now, it will not generally be true for other repositories. > For example, take a look at the Glassfish V3 Prelude repository: > http://pkg.sun.com/glassfish/v3prelude/release/
Actually, it doesn't assume that. If you'll look at the code in index.shtml or catalog.shtml, you'll note that it calls shared.get_releases() to get the release information, and if it can't, it falls back to just listing every package. I definitely had the glassfish repository in mind when I wrote this. > While many of the packages have 0-28.3 for the release/branch, there are > others with 0-15.1269, 0-0, 0-1, and 0-0.2. This will be the case > whenever a repository is a collection of packages that are produced by > more independent engineering teams. As an alternative, it would be > useful to also provide a menu choice for the most recent version of each > package (this should be the choice at the top of the menu). Since I rely on the "entire" package to be present in the catalog, this shouldn't be an issue (for now) as we currently rev the entire package for every build. I want a better way to get release and branch information, or to allow the user to browse by version, but for the moment, this works just fine for OpenSolaris. > shared.shtml, line 56 - hardcoding the mapping from branch numbers to > OpenSolaris release names in the code would seem to be a maintenance > problem, as this will need to be updated every time OpenSolaris is > released. Also, if another project unrelated to OpenSolaris happens to Yes, but it's a necessary evil until I have a more dynamic way of getting that information. Right now, I don't. I should probably add a "fixme" comment above that. Long-term I'd like to move that mapping information out into a separate template that can be easily edited, but I ran out of time for this version for it. > use 0.86, etc. for a branch number, they will get a 2008.05 showing up > in the output unexpectedly. While I see how this is useful, it would be > preferable if this could be derived from some other information such as > a repository configuration file. The idea of mapping numbered branches > to more meaningful names would be generally useful for other projects too. First, I want to be clear that I agree with that point. See above. Dan and I have been discussing what the best way to get this information would be. This sort of information is useful to more than just the depot facing pages, and should be in the catalog or in a special package, or somewhere else that can be shared between the client and server. Second, please note that the new depot facing pages are templates for a very good reason: I can't accommodate every usage case out there that different projects are going to have and I can't predict how people will really want to present their packages. Third, with the last point in mind, I won't be using the repository configuration file to store anything specific to the depot facing pages. I have purposefully re-designed the depot facing pages to be fully templated so that users of the depot can customise it for their particular project and/or target audience. This means all configuration that is specific to the depot facing pages must be done through the templates. Finally, it is very easy to customise the new depot facing pages and I have even introduced a new api that clients can rely on in the future to create their own custom interfaces to the depot. Users of the depot can simply copy the /usr/share/lib/pkg/web directory somewhere else, change the templates and then point their depot to that new directory with the --content-root parameter I recently added. > The second bullet in the search description "To find packages that > contain a specific file by path, include the leading '/': > /usr/bin/vim" depends on the resolution of issue 1059, although the > issue here has to do with a search on the repository rather than on a > local image as is the case in 1059. The use of a "/" at the beginning of > the file path is based on the assumption that an image that is going to > use this repository has "/" for the root. While this is true for the > OpenSolaris repository, it isn't generally going to be true for user > images. Also, the search output Value column doesn't match the search > input when the leading "/" is used. For example, if you search for > /usr/bin/vim, the search values are all usr/bin/vim which doesn't match > the what was entered. I would rather see a the following behavior: No, it doesn't. But that's how search on the client currently works. For the moment, my intent is to have search functionality that closely matches the client as much as possible. > a) If a search team has a leading slash, first do the search as given. > If there are results, display them. > b) If there are no results from (a), then strip the leading slash and > try the search again. > c) Don't mention that a leading slash has to be added to search terms. Again, my intent is to make the server search match the client search. Any changes to one should be made to the other through the search API. I don't want to diverge in behaviour from here and I want to rely on the API as much as possible for all behaviour. Diverging in presentation (layout, graphics, etc.) is fine, but I don't want to change the actual results that are returned. Example search from client: [EMAIL PROTECTED]:~# pkg search -r /usr/bin/vim INDEX ACTION VALUE PACKAGE path file usr/bin/vim pkg:/[EMAIL PROTECTED] ... I don't necessarily disagree with your suggestions, but I'm certain there were good reasons for making search work the way it does now. Brock might be able to better address this issue than I can. Thanks for the review, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
