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

Re: [RFR] Bits draft for Lintian 2.5.12



On 2013-04-17 21:14, Jakub Wilk wrote:
> * Niels Thykier <niels@thykier.net>, 2013-04-16, 22:06:
>> API stability not included, so packages should add dependencies on
>> Lintian accordingly.
> 
> Well, adding dependencies would be required even if we guaranteed API
> stability. :) Perhaps "dependencies" misses an adjective such as
> "strict" or "tight"?
> 

Indeed, going with "tight".

> Anyway, how strict the dependency should be?
> Is
>     lintian (>= 2.5.12), lintian (<< 2.5.13)
> enough, or should I use:
>     lintian (>= 2.5.12), lintian (<< 2.5.12+)
> ?

That is indeed a good question.

So far we appear to have been very conservative in "4 digit" releases
(e.g. 2.5.10.X) in the few times they have been used[1].  They appear to
only have been bug fix releases (not even introducing new tags).  I
would personally be fine with promising API stability for those releases
for now.
  With that in mind, that would be something like:

  lintian (>= 2.5.12), lintian (<< 2.5.13~)

If I am not mistaken.  We should probably stress the need for "~" in the
upper bound to avoid issues in stable backports.  (Please see attached
diff for the revised version)

> 
>> * Reduce the constant overhead in invocating Lintian's collections.
> 
> Typo: invocating -> invoking.
> 

Thanks.

~Niels

[1] Judging from the changelog there has only been one entry with that
kind of versioning prior to 2.5.10.1.  Anyhow.



--- bits-orig	2013-04-17 21:47:27.503203010 +0200
+++ bits	2013-04-17 21:46:59.095929669 +0200
@@ -21,7 +21,13 @@
 With Lintian 2.5.12 we have decided to open up for supporting for
 third-party checks.  For more information see [LM#3.3] or the "API"
 docs[API-DOC].  API stability not included, so packages should add
-dependencies on Lintian accordingly.
+tight dependencies on Lintian accordingly.  An example of such
+dependency is:
+
+  lintian (>= 2.5.12), lintian (<< 2.5.13~)
+
+Please be very careful to remember the "~" in the upper bound as
+Lintian is regularly backported to stable.
 
 Since these checks are not restricted to all of the design choices of
 Lintian itself, so it is (among other things) possible to (ab)use the
@@ -170,11 +176,11 @@
  * Decompress gzip files via PerlIO gzip (when available) to reduce
    the number of external fork/exec calls.
 
-   - libperlio-gzip-perl (Available in Wheezy)
+   - Enable by installing libperlio-gzip-perl (Available in Wheezy)
    - This may vastly improve the runtime of Lintian on some non-Linux
      systems.
 
- * Reduce the constant overhead in invocating Lintian's collections.
+ * Reduce the constant overhead in invoking Lintian's collections.
 
    - This overhead can be substantial for source packages that build
      many "small" binary packages.  Examples include freebsd-utils
@@ -184,7 +190,7 @@
 Things we still have not been able to solve:
 
  * Lintian is still slow on packages with a lot of manpages.  The root
-   cause is running man one each manpage, which is not optimized for
+   cause is running man on each manpage, which is not optimized for
    this use-case.
 
    - Symptom: checks/manpages is a bottleneck.

Reply to: