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

Bug#249414: lintian: Fails to detect usr-doc-symlink



On 2004-07-02 Jeroen van Wolffelaar <jeroen@wolffelaar.nl> wrote:
> On Fri, Jul 02, 2004 at 09:48:24AM +0200, Andreas Metzler wrote:
> > On 2004-07-02 Matthias Klose <doko@cs.tu-berlin.de> wrote:
> > > Enforcing the exact dependency via depends is a bad thing, seen from a
> > > practical side. auto builders cannot get the dependencies on any/all
> > > combinations done unless all architectures have catched up
> > > (i.e. gcc-3.X runs a testsuite on build, which depends on locales).
[...]
> > Indeed. See e.g.
> > http://lists.debian.org/debian-policy/2004/01/msg00034.html

> The solution prevented in that thread is, as someone else calls it,
> "horribly gross"[1].

> Since one cannot look into the future, I really don't understand why one
> doesn't follow the most logic way to proceed here:

If I am a little familiar with the package I can look a little bit in
the future and know which version-numbers are possible for the next
release, e.g. almost every sane numbering will fullfill
(upstreamversion + 1)-0.1 >> upstreamversion.0-0

> - uploading a package that requires at least version X of a certain
>   package, depend on at least that version (ok, that was done already)
> - then, instead of already depending on strict smaller versions of a
>   certain package, which always gives the risk of problems, since you
>   cannot look into the future, simply on the _next upload_, conflict
>   with the then-old version of the depending package, to cater for this.
>   So:

> Package: xlibs-static-dev (1.2)
> Depends: xlibs (>= 1.2)

> Package: xlibs (1.2)

> (later)

> Package: xlibs-static-dev (1.3) [incompatible with xlibs 1.2]
> Depends: xlibs (>= 1.3)

> Package: xlibs (1.3)
> Conflicts: xlibs-static-dev (<< 1.3) [because xlibs-static-dev 1.2 can't
>                                       be with xlibs 1.3!]
[...]

The strongest argument against this is that <<conflicts are evil
because they force apt to split the upgrade in lots of small clusters
(--> policy for details).

The other point is that your solution is one of "maintainer checks
with every upload whether he has to change debian/control"-kind while
people just want a automatic "depend on the same upstream-version".

The automatic update will make some dependecies unnecessarily strict
(perhaps foo-12.3.0 *could* work with foo-common-12.3, but I doubt
every maintainer is going to do this basically unneccessary work)
but this is more of a cosmetic problem imho. OTOH a forgotten manual
change in debian/control will probably yield an RC bug.
              cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"



Reply to: