Hello again.
I updated my proposal according to discussion with Danek:
http://wikis.sun.com/download/attachments/45908778/design.txt
http://wikis.sun.com/download/attachments/45908778/high-level.png
I still am not clear on some IPS related points. Can you please advice
me on my two remaining questions?
1) What is the best way to call IPS from inside of the G11nInstall
interface code? Call pkg as an external command? E.g.:
os.system('/usr/bin/pkg ... ').
2) Are following commands suitable for searching G11n file tags (e.g.
language, territory) at entire IPS image or repository?
Would following commands consume too much system/network resources?
# Listing all G11n-related tags available at image:
$ pkg contents -t dir,file,link \
-o action.name,path,language,territory,...
# Listing all G11n-related tags available at network repo:
$ pkg contents -r -t dir,file,link \
-o action.name,path,language,territory,...
# Searching G11n related files at image or repo:
$ pkg search [-l|-r] usr/lib/locale
Thank you,
Jan
Jan Trejbal wrote:
> 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
> pkg-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
