[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Vendor specific data files



Niels Thykier <niels@thykier.net> writes:

> Hi,

Hello,

[...]

> 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?

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"?


> 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


> 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?

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?

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/'.

> [2] A variant here is to only have vendor dirs and move all current data
> files into "data/debian/".

Is that the issue?

Regards.

Footnotes: 
[1]  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608884

[2]  http://lintian.debian.org/manual/section-2.5.html

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

Attachment: pgpt5aNjU7yeB.pgp
Description: PGP signature


Reply to: