Hello Danek, thank you very much for your comments and advices. See my replies in-line.
Danek Duvall wrote: > On Fri, Aug 15, 2008 at 09:33:18AM +0200, Jan Trejbal wrote: > >> Package attributes: >> set name=language value=fr >> set name=encoding value=UTF-8 >> depend fmri=pkg:/SUNWlang-common type=require >> >> File tags (ULL=usr/lib/locale): >> PATH LANGUAGE TERRITORY ENCODING MESSAGE >> $ULL/fr.UTF-8/LC_MESSAGES fr UTF-8 true >> $ULL/fr.UTF-8/LC_MESSAGES/*.mo fr UTF-8 true >> $ULL/fr_FR.UTF-8/fr_FR.UTF-8.so.3 fr FR UTF-8 >> $ULL/fr_CA.UTF-8/fr_CA.UTF-8.so.3 fr CA UTF-8 > > Why are you putting language and encoding both on individual files and on > the package? Note that filters don't apply to packages, just to package > contents. The desire is to have package boundaries defined by > functionality, and that all documentation and message catalogs are in the > same package that delivers the functionality, with only desired components > filtered in by the user-chosen filters. You are correct, the package attributes does not make sense. Maybe for some special cases like font or input method packages - separated G11n packages. But we will need to tag all files of those packages, anyway. I will remove language and encoding attributes from proposal. Also, I understand that the Language/Locale.get_packages() functions (returns list of packages which must be installed (removed) to support this language) are just informative and may not be much of use. Since tags and filters work with higher granularity. > >> See more details and examples at following documents: >> http://wikis.sun.com/download/attachments/45908778/design.txt > > This URL has a strange content-type (application/x-zl-download), so I can't > actually read it in my browser. Can you correct that? Sorry, I fixed that. I relied on wikis.sun.com to detect content-type automatically. > >> http://wikis.sun.com/download/attachments/45908778/high-level.png > >> 1) Does IPS currently (or will in 2008.11) support custom tags, >> attributes, and filters from examples described above? Also, will >> interface consumers be able to use IPS filters for packages/files >> installation and removal? > > Actions can carry arbitrary attributes, as can packages. Filters can > operate on any attribute (modulo bug 322 where they can't operate on set > actions -- package attributes), and you can already specify filter on > package installation. There certainly needs to be some support for > image-wide filters, but the basics are there. Since we will most likely use tags only, we are fine with bug #322. But image-wide filters are interesting to us. Before those are available, we will need to determine list of packages and then apply filters to them. Something like following. canada= G11nInstall.Language("fr_CA") pkgs= canada.get_packages() fltr= canada.get_filter() for p in (pkgs): p.apply_filter(fltr) After all, the get_packages() function seems to be useful. > >> 2) Is there (Python) IPS interface, which I can call to retrieve the >> custom package attributes and file tags? > > Just parse the actions and find the attributes you're looking for. Right, but I am not sure is there is any Python interface for this. Is there any available? Another option is to call pkg command, which you may suggest me as the only official IPS interface. If that's the case, can I re-use Python objects which are part of IPS sources, when implementing my interface? E.g. Image, Package, Repository objects. The interface sources would need to be part of IPS gate. Is that possible? > >> 3) Where can I define and modify custom attributes & tags for our (G11n) >> packages, which were delivered to pkg.opensolaris.org and LiveCD? > > You should also read Stephen's Tags and Attributes document, available via > a search through the pkg-discuss archives. > > We don't yet have all the mechanism we need to add data to packages which > have already been published, though obviously in order to add locale and > documentation information to packages, we'll need that ability. I guess you mean following document: http://mail.opensolaris.org/pipermail/pkg-discuss/2008-March/002352.html I may not need to modify data of published packages. Re-delivering packages is possible. Then, I can use pkgsend command to define custom file tags, right? > >> I also welcome any comments on design of the proposed interface. You may >> see a way how to make it simpler, more efficient, etc. >> For example, I am not sure if using Image and Repository Python objects >> as input, and Filter object as output of the interface is the best thing >> to do. > > I think that you're missing a layer that needs implementing, not just for > this, but for other kinds of filtering as well. We don't have a way to > retrieve all the locale meta-information available from the packages a > system knows about -- i.e., what languages are available, what encodings, > etc. -- so that a user can select them, rather than having to guess at > their values. > > That seems useful -- not just for locale information, but also to list, say > what architectures are available, or other possible package variants -- and > we don't have a good way to do that at the moment. You're not proposing a > mechanism for this, but something on top of such a hypothesized layer, > right? Yes. I thought IPS can give me information about meta data of all packages in image and at network repository. Why I cannot use following `pkg contents` command to get a list of all tag values? # pkg contents -t file -o action.name,path,language,territory,encoding, message,documentation [-r] I guess running above for all packages present at system or network repository would take a very long time and cause big network traffic. I rather should use a static table of tags and their values. But that is still doable considering that list of languages and territories are standardized (ISO-639, ISO-3166), and does not change often. > > As far as your interface goes, it seems a reasonable way to encapsulate the > g11n aspects of a system. It shouldn't worry about repos, just images, and > it's not clear where some of the information would come from (such as the > descriptions of various objects). You'll also need to move away from > separate l10n packages -- I don't see the need for such things anymore. I care about network repos, because I need to request meta data from it. For example list of available language tags. I thought -r can help me to call the same commands to image and repo. I forgot to mention in proposal, that some of the information will not be stored as tags in IPS. For example Language and locale description's and their translations. We have message catalogs for that. I that separate l10n packages are not needed in OpenSolaris. We are not using them for new deliverables, but you can still find some older separated l10n packages. > I'm also skeptical of "translation progress" and "suggested locale", but > neither appear to affect the architecture of IPS or filtering, so I suppose > I don't care too much. Those are additional functions. I may not implement them unless requested by interface users. > > Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
