Re: Vendor specific data files
On 2011-12-16 22:40, Daniel Dehennin wrote:
> Niels Thykier <niels@thykier.net> writes:
>
>> Hi,
>
> Hello,
>
Hi,
Thanks for the feedback. I am quoting your reply in full for the sake
of debian-lint-maint. :)
> [...]
>
>> I am proposing the "Vendor Data Files" as an extension to the current
>> "Vendor Profiles". It is not a "Silver Bullet" (tm), but it should
>> solve #648777 and #649852 just nicely.
>
> +1
>
> [...]
>
>>
>> The second alternative would be to implement Vendor specific checks
>> (#359059). However, I think it would be a terrible solution to #649852
>> (effectively, suppress the debian tag and re-implement with an exception
>> for the particular field).
>
> +1, I think about checks as package structure validation, each vendor
> only need to supply the set of values for each "structure item" (like
> possible distribution names for examples).
>
>
>> Proposed solution:
>> ------------------
>>
>> Technically I suggest we create a "vendor" directory in data for this
>> purpose. Each subdir maps to a vendor and inside the vendor subdir is a
>
> [...]
>
>> If a file is missing form the vendor data dir, we look for a data file
>> in its "parent vendor" directory until we run out of "parent vendors".
>> At this point we look for it in data/, where our default file will
>> be[2].
>
> +1
>
> 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.
> If I have a "build spooler", I want it to be "bleding edge", the build
> machines and chroots are version specific, is it better to run lintian
> on the build machine or the "build spooler"?
>
I would say it depends on the build guidelines for the distro in
question. In Debian, generally you want "bleeding edge" Lintian for
"bleeding edge" packages.
We see frequent backports of Lintian to stable-backports to help
developers, who have a stable system.
I assume this holds for most other Debian-based distros, but that is
only a guess on my part.
>
>> Extension:
>> ----------
>>
>> The above is the "simple" solution to the problem. Though I am thinking
>> we could do with extending it a bit. The problem I want to address is
>> that changes to the Debian file will not automatically apply to
>> derivative files. Depending on the data file in question this may (or
>> may not) be a good default.
>> My proposal here would be to include some simple "processing"
>> statements to our data files. I believe the following will do:
>>
>> @include-parent
>> @delete <key>
>>
>>
>> The semantics of them are:
>>
>> @include-parent
>
> [...]
>
>>
>> @delete <key>
>
> [...]
>
>> With the extension, I believe we should be able to handle most common
>> cases, avoid some copy-waste and (more importantly) "out-of-date" data
>> files for derivatives.
>
> Why not making @include-parent the default?
>
> I think default include will lower the need to redefine things:
>
> - people who need to redefine everything get the same amount of works:
> everything is included and they need to set/delete values
>
> - people who need few modifications will just need to define few
> set/delete values
>
> Default include will permit to keep the "policy compliance" up to date,
> when parent change something:
>
> - people how don't want it need to update their data to set/delete value
>
> - other just need to do nothing if the value is ok for them, or set it
> to something else
>
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.
>
>> Open Questions:
>> ---------------
>>
>> 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?
> The dpkg-vendor origin seems not well documented[1], not the case of
> lintian profiles[2]. I even doesn't know dpkg-vendor before someone
> point me to it on IRC recently.
>
>> Open question: would it be better to have a "Data-directory" field in
>> the Lintian vendor for vendors that need this?
>
>> How do we handle "sub-vendors" (e.g. --profile vendor/group)?
>> - Trivially solved if we use "Data-directory" in the Profile (see
>> above)
>> - It is not unreasonable to think that if #359059 is fixed there will
>> appear some "debian/pkg-$group" profiles/checks.
>> - Should a sub-vendor be allowed to have its own data-files
>> - obsolete-packages and deprecated-makefiles comes to mind as
>> possible use cases.
>
> [...]
>
> Not sure to understand this point.
>
> Instead of a default value of 'LINTIAN_ROOT/data/<vendor>', let the
> vendor specify the directory where its data are?
>
Basically yes, but ...
> If we can have some collision between group names and vendor names, then
> could we put the vendor data under
> 'LINTIAN_ROOT/vendors/<vendor>/data/', similar to you [2] point.
>
> Groups data will under 'LINTIAN_ROOT/vendors/<vendor>/<group>/data/'.
>
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.
>> [2] A variant here is to only have vendor dirs and move all current data
>> files into "data/debian/".
>
> Is that the issue?
>
No, it was just a suggestion to move the default data set from
LINTIAN_ROOT/data/ to the "Debian vendor specific data" directory.
> Regards.
>
> Footnotes:
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608884
>
> [2] http://lintian.debian.org/manual/section-2.5.html
>
~Niels
Reply to: