On 2011-06-01 09:39, Jeremiah Foster wrote: > > On Jun 1, 2011, at 00:31, Niels Thykier wrote: > >> Hey, >> >> I finally pulled myself together and spent a little more time on the >> vendor-profile branch. On top of the basic profile support I added last >> time (back in April) we now have non-overridable tags. >> However, there are a number of things I would like some comments on, >> which I hope you will take some time to look at. >> >> First off - currently the base Debian profile and the ftp-master profile >> have to be generated via "debian/rules profiles". When the main profile >> is generated, the generator records all the checks in "checks/" and >> enables (only) those in the profile. This has the advantage that if >> someone dumps their own checks in the checks dir, Lintian will now >> ignore it in the Debian profile[1]. > > This sounds like a nice feature. >
Thanks, I figured it would make it easier for us to enable user specified checks later with this. :) >> The problem is how to handle this profile generation; for now I have >> not included the generated profile in git. > > I'm not sure what you mean here - do you mean how to create profiles as in a > type of configuration? > No, I mean in order for Lintian's default profile to include all checks we ship by default, they have to be added to the profile. Currently I have a script to write this profile. This script is run during the build/test process and can be invoked manually by running "debian/rules profiles" as well. Currently Lintian does not load a profile by default, so you can still do a "git clone, set LINTIAN_ROOT and run" to use the development version of Lintian. This is a very nice property that I would very much like to keep. The problem is that according to the specification, we said there would be a "default" profile that would be loaded in the absence of a specific profile being passed. The problem is how to we ensure that the Debian profile is available and up to date in the git repository so we keep the "git-clone-run" property. Which brings us to ... >> As far as I can tell the >> best solution we have so far is to do just that and remember to update >> it when adding a new check (similar to t/COVERAGE or our data files). > > I'm not familiar enough with the mechanism to comment effectively. I'd be > happy to be a vendor profile guinea pig however and test vendor profile > generation if that would be useful. > Personally I think the best solution is to handle it like our data files. We push it to the repository and then push updates as we add or remove checks; perhaps we can even do it like the "perl-provides" that warns if the file is out dated? That being said - testers / guinea pigs welcome. Currently it does not load any profiles by default so you have to use --profile (or $LINTIAN_PROFILE/$DEB_VENDOR) to test it. Otherwise it will act like the normal Lintian. You can see if it uses profiles by passing --verbose (N: Using profile $profile_name.). The only really fun profiles right now are "debian" (normal lintian) and "debian/ftp-master-auto-reject"[1] (auto-reject tags with non-overridable tags). The "ubuntu" profile is basically the "debian" profile except for one or two tags. In the long run I expect to make the "debian" profile extend the auto-reject profile, but I have not done that yet. Particularly this is the only way to test that non-overridable tags are configurable (without having to write a new profile). [1] Also aliased -F or --ftp-master-rejects. >> On a related note: we can avoid rebuilding the ftp-master profile if we >> change the specification of profiles to allow referencing files >> containing tags. I think this might be a cleaner solution (open the >> ftp-master profile if you do not understand what I mean). >> >> Secondly there is the handling of the "default" profile. Originally I >> planned for this to be a symlink because it was easier (code-wise), but >> does git handle symlinks sanely? If not, we lose the "git clone + set >> LINTIAN_ROOT + run" property we have now in master (even with the >> changes above). >> Would it be better for us to instead rely on dpkg-vendor to supply a >> default profile name (either in general or in the absence of the default >> symlink)? > > I think relying on dpkg-vendor would be the logical thing to do, but this is > from a fairly naive perspective. Also instead of using the "default" symlink? Particularly we have to backport this as well; as I recall dpkg-vendor is available in Squeeze, but is it available in Lenny or is it okay if it isn't? >> >> Third, do we install profiles in /usr/share/lintian by the default or in >> /etc/lintian/profiles/ ? As I see it, there is a problem with both >> ways. The first one does not work too well with --root / $LINTIAN_ROOT >> changes; on the other hand if we install in /etc, it would overrule our >> development profiles by default. So I am leaning towards keeping them >> in $LINTIAN_ROOT, but I figured I would mention it. > > Wouldn't the expectation that /etc/lintian/profile/foo override > /etc/lintian/profile/debian? So wouldn't /etc/lintian/profiles be the right > place? This seems consistent with Linux Standards Base practice. > I am talking load order here (like include paths in gcc). Lintian checks the following directories (in order) for profiles: $HOME/.lintian/profiles /etc/lintian/profiles $LINTIAN_ROOT/profiles To clear any misunderstanding, the expectation is that /etc/lintian/profiles/vendor/foo.profile would override $LINTIAN_ROOT/profiles/vendor/foo.profile. Whether we use vendorX or vendorY depends on --profile, $LINTIAN_PROFILE or $DEB_VENDOR. So my question was, if we install the profiles by default into $LINTIAN_ROOT then users having an outdated $LINTIAN_ROOT (e.g. there own in ~/.lintian) will get "weird errors about profile X not being present". On the other hand, if we install the profiles in /etc/lintian/profiles, they can change the $LINTIAN_ROOT as much as they want and the profiles are still there. However this kills the "git-clone-run" property, because the development version would load the profiles in /etc/lintian/profiles and not the ones you are messing with. > Regards, > > Jeremiah > ~Niels -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
