Hi, I have been coding a bit and I got an idea that I would like to share before just merging my branch (at [1]). I originally wanted to start on the vendor-specific data files, but it turned into some rather large structural changes. Hench this mail.
There were some observations that lead to these changes. First, we currently have four different pieces of code, from where we read the check "desc" files or do a dir-listing of the checks dir[2]. The second observation was that if we are getting vendor-specific data files, then we should always load a profile in frontend/lintian[3] as some tags depend on the data files. Third, Lintian::Tags and Lintian::Profile are both used to determine if a tag should be suppressed or not. The branch makes Lintian::Profile responsible for loading tags + checks and determining which checks/tags are active. Should we later decide to do "3rd party checks" on top of vendor profiles, these changes may turn out to be even more useful. Lintian::Tags will generally use a profile to do its job suppressing disabled tags (and ignoring overrides). Strictly speaking the branch leaves some parts of Lintian::Tags redundant now. If there are not any objections, I will go ahead and merge this within a weeks time or so. ~Niels [1] http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/profile-tag-container [2] frontend/lintian, reporting/html_reports, Lintian::Profile and Lintian::Tags. [3] Currently we do not load a profile if either --tags{,-from-file} or "--check-part" is used. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
