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