Niels Thykier <niels@thykier.net> writes:
> Thanks for the feedback. I am quoting your reply in full for the sake
> of debian-lint-maint. :)
Ok, I include that list in my reply.
[...]
>> Do you think there is a possibility to have version specific under each
>> vendor?
>>
>
> "You" (i.e. the vendor) could encode the version as a part of the
> profile name (e.g. debian/v6_02 or ubuntu/v1110). This plus a data dir
> for each Lintian profile should solve that.
Ok for that, with a layout as suggested at the end it could be easy to
read/use.
>> Why not making @include-parent the default?
[...]
> Personally, I think an explcit "@include-parent" is better than it being
> default semantics. It tells the reader that there is more to the file
> than the lines in it.
>
> As a Lintian maintainer, either way is fine for me because I will be
> working with it often. But I am afraid "newcomers" may find it
> surprising that parent files are parsed by default.
Ok, my explanation was not very clear:
As a vendor, Extending, say, "debian/main", do I need to provide:
- a full data/ directory?
- just files I wanted different?
I agree with the explicit "@include-parent" when redefining a "data
file", but I prefer not to have to copy-and-adapt the full debian/main
data/.
For example, I'm vendor "foo", I just Extends "debian/main" but my
distribution is called "quux", I only want to provide one file in a
lintian-vendor-foo package:
"$LINTIAN_ROOT/vendors/foo/main/data/changelog-file/foo-dists"
with the regexp (or list) of my distributions: "quux(?:-(?:proposed-updates|security|backports))"
If I want to use "debian/main" distribution names in my project, I need
to provide an "@include-parent" line
I hope I do not need to provide all the other files, containing only
"@include-parent".
So, we can call this something like "inheritance of nonexistent data files".
>>> Open question: Is parent vendor defined in terms of "dpkg-vendor" or in
>>> terms of Lintian profiles's "Extends:" relation? Which is less
>>> confusing/most useful?
>>> - I admit thinking dpkg-vendor for the first hour of writing this
>>> email.
>>> - But would the "Extends" relation be more useful?
>>
>> Why not intersection of both?
>>
>
> I do not see how you could that. Do you have a proposal for how that it
> would work?
Not really, I'm not confident with dpkg-vendors, mostly due to the lack
of documentation ;-)
My problem is that dpkg-vendors provide a Parent but no profile name,
which seems to be specific to lintian.
So, here is a try:
- if a "--profile" command line argument is provided to lintian, skip
dpkg-vendors as the information could be unavailable on the machine.
Like check an ubuntu package on a debian system
- no "--profile" command line argument is provided to lintian:
1. Get current vendor origins with dpkg-vendors
2. Load lintian main profile of the current vendor:
- Is there an "Extends"?:
- Yes: Is there a dpkg-vendors "Parent"?
- Yes: miss-match?
- Yes: raise Error
- No: recurse to 1. with lintian profile "Extends" vendor as
current vendor
- No: recurse to 1. with lintian profile "Extends" vendor as
current vendor
- No: Is there a dpkg-vendors "Parent"?
- Yes: recurse to 1. with dpkg-vendors "Parent" vendor as
current vendor
- No: End
I wonder if someone use the dpkg-vendors "Parent" field.
I think we can not tell which one is the reference if the dpkg-vendors
"Parent" does not match a lintian profile "Extends", so I raise an Error
in that case to let people handle it.
> now you mention it, using something like
>
> LINTIAN_ROOT/vendors/$PROFILE_NAME/data/
>
> it probably a better idea. It would be consistent and would come with a
> built-in namespace.
+1
Regards.
--
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1
Attachment:
pgpqIvtrkFvwj.pgp
Description: PGP signature