Shawn Walker wrote:
Rich Burridge wrote:
Shawn Walker wrote:
Danek and I discussed last week if there was a better option here than having a centrally located classifications file. After discussion, it became clear that we didn't really need one at all.

Instead, the client API will be changed to read the classification information for all packages each time we cache the catalog data and then cache the resulting package mapping and set of classifications.

In turn, the API will provide a method to get this set of classifications, so no file will be needed.

Your changes to check_classifications seem fine though, I would just drop the _resources/ directory and contents from your webrev.

Part of the reason for doing this was so that there would be a single list of valid categories/sub-categories available "somewhere", then could be used by applications such as Source Juicer, to determine whether the category/sub-category provided by a new package spec file was valid. As new valid categories/sub-categories
were determined, then the file would be updated accordingly.

Your proposed change seems to disqualify that.

If this shouldn't be via a "static file located somewhere centrally (like a DTD would be)"
then how should it be done?

I think the sourcejuicer case is special, as they want to work from a pre-defined list of categories specific to Sun or the community. There has been some discussion as to whether the freedesktop.org classification scheme should be available for sourcejuicer.

Really? I hadn't heard that (and I thought I was on all the right aliases).
Can you point me to that discussion please?

Obviously, the centralised classifications file you're proposing wouldn't cover that case.

For now, I think our best option is to simply generate and commit the classifications file to our gate as a reference to be used when importing via solaris.py or for those that want the reference file.

In that case, I'm looking for two code reviewers for the current webrev:

   http://cr.opensolaris.org/~richb/pkg-9002-v2/

and I should fegedabout trying to put it somewhere that others can read it.

Do I have a +1 from you for the current changes?

In short, I don't have a good answer for that particular usage case, but the pkg(5) client won't be using a centrally located file.

Understood.

Thanks.

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to