Debian Bug report logs - #667614
lintian: Please query distro-info for getting a valid list of Debian/Ubuntu distributions

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Benjamin Drung <bdrung@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: lintian: Please query distro-info for getting a valid list of Debian/Ubuntu distributions

Date: Thu, 05 Apr 2012 12:40:27 +0200

Package: lintian
Version: 2.5.6
Severity: minor

Dear Maintainer,

Please use `debian-distro-info --date=<iso 8601 date> --supported'
to get a list of valid Debian distributions and
`ubuntu-distro-info --date=<iso 8601 date> --supported' for a list of valid
Ubuntu distributions. You can use libdistro-info-perl if you want to avoid
a program execution.

The output of the distro-info scripts can replace the static list in
vendors/debian/ftp-master-auto-reject/data/changes-file and
vendors/ubuntu/main/data/changes-file.

FYI, distro-info will be backported to squeeze and I will keep the
distro-info-data package up-to-date.

Message #10 received at 667614@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Benjamin Drung <bdrung@debian.org>, 667614@bugs.debian.org

Subject: Re: Bug#667614: lintian: Please query distro-info for getting a valid list of Debian/Ubuntu distributions

Date: Sun, 08 Apr 2012 22:03:31 +0200

On 2012-04-05 12:40, Benjamin Drung wrote:
> Package: lintian
> Version: 2.5.6
> Severity: minor
> 
> Dear Maintainer,
> 
> Please use `debian-distro-info --date=<iso 8601 date> --supported'
> to get a list of valid Debian distributions and
> `ubuntu-distro-info --date=<iso 8601 date> --supported' for a list of valid
> Ubuntu distributions. You can use libdistro-info-perl if you want to avoid
> a program execution.
> 
> The output of the distro-info scripts can replace the static list in
> vendors/debian/ftp-master-auto-reject/data/changes-file and
> vendors/ubuntu/main/data/changes-file.
> 
> FYI, distro-info will be backported to squeeze and I will keep the
> distro-info-data package up-to-date.
> 
> 
> 

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.

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]).

~Niels

[1] http://lists.debian.org/debian-derivatives/2011/12/msg00008.html

Message #15 received at 667614@bugs.debian.org (full text, mbox, reply):

From: Benjamin Drung <bdrung@debian.org>

To: 667614@bugs.debian.org

Subject: Re: Bug#667614: lintian: Please query distro-info for getting a valid list of Debian/Ubuntu distributions

Date: Sat, 21 Apr 2012 23:44:12 +0200

[Message part 1 (text/plain, inline)]

Am Sonntag, den 08.04.2012, 22:03 +0200 schrieb Niels Thykier:
> On 2012-04-05 12:40, Benjamin Drung wrote:
> > Package: lintian
> > Version: 2.5.6
> > Severity: minor
> > 
> > Dear Maintainer,
> > 
> > Please use `debian-distro-info --date=<iso 8601 date> --supported'
> > to get a list of valid Debian distributions and
> > `ubuntu-distro-info --date=<iso 8601 date> --supported' for a list of valid
> > Ubuntu distributions. You can use libdistro-info-perl if you want to avoid
> > a program execution.
> > 
> > The output of the distro-info scripts can replace the static list in
> > vendors/debian/ftp-master-auto-reject/data/changes-file and
> > vendors/ubuntu/main/data/changes-file.
> > 
> > FYI, distro-info will be backported to squeeze and I will keep the
> > distro-info-data package up-to-date.
>
> 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.

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

My proposal is to allow providing code to get a list of series instead
of requiring a hard-coded list in data/changes-file.

-- 
Benjamin Drung
Debian & Ubuntu Developer

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 667614@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Benjamin Drung <bdrung@debian.org>, 667614@bugs.debian.org

Subject: Re: Bug#667614: lintian: Please query distro-info for getting a valid list of Debian/Ubuntu distributions

Date: Sun, 22 Apr 2012 00:54:48 +0200

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

Send a report that this bug log contains spam.