Bug#249414: lintian: Fails to detect usr-doc-symlink
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).
>
> [Keeping the long cc-list, except for Mathias as _he_ moved this to
> the list. ]
You can drop the four lintian maintainers... as they get the bug mail.
> 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:
- 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!]
Nice, clean solution, not involving guess what the next incompatible
upload will be... who knows the next upstream version is a minor bugfix
release, so they _can_ co-exist...
> lintian should not try to be more strict than policy for
> /usr/share/doc symlinks, policy only requires "/usr/share/doc/package
> may be a symbolic link to another directory in /usr/share/doc only if
> the two packages both come from the same source and the first package
> Depends on the second."
As I said already[2] in this bug trail:
| Hm, we trust to the maintainers to get this kind of dependencies right
| in most cases... That is, a depends on the latest significantly (that
| is, incompatible) changed version, and conflict on the latest
| incompatible package.
I still think that also for copyright files, the mainainer should simply
care of proper depends/conflicts when the copyright file changes
significantly (in the legal sense).
> On a sidenote we've done away with the =depends in libgnome2-common by
> using this in debian/rules
>
> upstream-version := $(shell dpkg-parsechangelog | sed -n '/^Version: /{s/^Version: \(.\+\)-[^-]\+/\1/;p;}')
> DEB_DH_GENCONTROL_ARGS := -- -VUpstream-Version=$(upstream-version)
>
> and this in debian/control
> Depends: ... libgnome2-common (>= ${Upstream-Version}), libgnome2-common (<< ${Upstream-Version}.0-0)
>
> any suggestions for improvement?
See above: simply don't do this kind of hack...
--Jeroen
[1] http://lists.debian.org/debian-policy/2004/01/msg00037.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249414&msg=15
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: