On 2012-04-21 23:44, Benjamin Drung wrote: > Am Sonntag, den 08.04.2012, 22:03 +0200 schrieb Niels Thykier: >> On 2012-04-05 12:40, Benjamin Drung wrote: >>> [...] >> >> Hi, >> >> I find the idea interesting, but I have two major concerns here. First, >> distro-info (and its perl API) appears to assume that there are only >> "two" vendors (namely Debian and Ubuntu). For me, this seems like a >> regression now that we have allowed vendors to deploy their own data files. > > Every vendor may have its own release process and therefore need its own > data file and processing script. Debian has no LTS release and Ubuntu > has nothing like testing. Other vendors can file a bug against > distro-info to get them supported. >
I am not questioning that vendors can request to become supported in distro-info, but at the moment distro-info does not appear to have an API suited for handling more than two vendors. I based this on three observations I made from a brief look at the distro-info source code (i.e. the git repository linked from the PTS): * It appears that to add a new vendor you have to implement the same logic in 4-5 different languages. * In some languages, the "modules"/"classes" for "all" vendors are embedded in the same file. * There appears to be absolutely no documentation for how to add a new vendor. It is possible that the first two points makes sense for the given "problem", but my initial thought is "This will not scale (in a sane way)". Mind you, it is not my intention to bikeshed your code. I just do not see why distro-info would be easy to (re-)use for other vendors and there appears to be no documentation explaining the (dis)advantages of the design. That being said, even if you fixed all of that - I still have some concerns with how to integrate this with Lintian (see below). >> My other concern is that in order to use distro-info, it seems that I >> need to know the "vendor" the package is targeted for. Unless we expose >> Vendor information to checks, they will not be able to do this. While >> we could do that, I (still) think it would be a bad idea (as explained >> in [1]). > > Doesn't a profile needs to know target vendor? The distro-info calls > should be part of the vendor profile. > Sure, the profile "knows" the target vendor but the profiles do not run checks (i.e. emit tags). And the checks do not have access to (or knowledge of) profiles, so I do not see how letting the profile call distro-info would help. > My proposal is to allow providing code to get a list of series instead > of requiring a hard-coded list in data/changes-file. > I know and I appreciate the idea. But to me, it seems that we are stuck between re-adding vendor specific code (which I have been trying to get rid of) and maintaining a data file/table (status-quo). ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
