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:
pgpXXviZEwwmu.pgp
Description: PGP signature