On 07/11/12 09:23 AM, Danek Duvall wrote:
Tim Foster wrote:
http://cr.opensolaris.org/action/browse/pkg/timf/pkglint-grab-bag/webrev
Thanks for taking a look.
Have you run this over a recent WOS build to see if any of the new tests
are triggering warnings?
Yes, we're getting good mileage from the new check for SMF fmris, with
lots of new WARNINGs, but no new ERRORs.
pkglint_action.py:
- line 745: either merge into the previous paragraph or put a blank line
between them. Line 747 probably should be separated and indented, too.
Ok.
pkglint_manifest.py:
- line 513: if you use attrlist(), then you don't need the isinstance()
check on line 518.
Ah, cool - thanks.
- line 550ff: is there no code that could be reused to parse the config
file?
Not that I've been able to find. There's some in pkg.actions.attribute,
but didn't seem to do what I was after - specifically, it doesn't pull
apart the comma-separated list of categories.
- line 575: delete blank line
- line 644: it's not possible to skip a subtest like this, is it? I
would think that not having a classification is something that we might
require in Solaris, but not something everyone is going to care about
(particularly since it's not especially useful, IMO).
It would need to be marked as linted in all manifests that want to avoid
it, or more forcefully, we can move this test back into the
opensolaris-specific checks.
Traditionally, we've always checked for 'info.classification' to allow
the GUI to display 3rd party packages in their proper categories, but if
we care less about info.classification, then now's the time to move it.
- line 674: ".xml"?
That makes sense.
- line 677: I'd just use "not (A or B)" or "not A and not " rather than
use any().
Ok.
t_pkglint.py:
- line 650: square bracket should be on the next line, below the "c" of
"cmdlines".
Sure.
pkglintrc:
- Will this change require any consolidations to modify an existing
pkglintrc?
No, all consolidations that use pkglint today (that I know of - ON, X,
Userland and IPS) use their own pkglintrc file, which wouldn't have the
'exclude' directive. I'm checking with RE at the moment.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
