Re: Status on Vendor Profile
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
Reply to: