Stephen Hahn wrote: > (So this response is further along, and seems timely to send...)
A nice and clear synthesis; thank you. > 10. Package to SCM linkage. Since we don't have > consolidation-spanning packages, these should be easier than the > ARC linkage--some changeset must have produced this version of > the package. Aside from documentation... we currently provide all the man pages for ON in SUNWman, which is not part of ON (possible org bug :-)). Localization would also likely be appended from different SCMs, so this may need more thought. Clearly, per-file tagging is also possible, so a package w/ 90% files from SFW could carry that SCM tag, and this could be overridden for individual files... > > 13. Directory tags. Yes, all actions can carry tags. Yes, filters > should affect these actions, too. Note that filtering out directories will prevent them from being created only if there are no files in those directories; IPS does create (and cleanup) directories that are implicitly created. > > 14. Icons. I'll need more use cases/justification of why these need > to be actions. (How would you identify different icon sizes and > types?) My preference is to make this kind of information a URL > tag/attribute, and move responsibility to the client. (Since > every published file has a URL, that's not as big a deal as it might > appear...) > Wouldn't a more general and powerful search function handle this? Having a package publisher supply a pkg.pkgmgr.icon property that provides a URL to retrieve such would seem simple enough. Perhaps svg icorns would be best :-). > 15. Additional tags. Yes, we need to attach tags as packages get > through additional assessments. What's less clear is whether > some of these are, in fact, Solaris or Sun only--like Section 508 > (USA accessibility law)--or of broader interest. > > com.sun,assessment.section508 > com.sun,assessment.open-source > [info.arc_url] > > where each of these carries a URL or identifier (potentially only > of use to the publisher). > There are general search tags that would be useful.... rather than expecting/hoping the pkg hierarchy to provide all useful classification, being able to tag pkgs would make finding content in a large repo much easier. For example, quake might come under application/game, but could be tagged OpenGl, FirstPersonShooter, etc. The general utility of all metadata is greatly enhanced if it's searchable; show me all packages tagged OpenGL (rather than trying to search for pkgs that have dependencies on a particular library) would be nice. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
