On Fri, Jul 02, 2004 at 09:48:24AM +0200, Andreas Metzler wrote: > On 2004-07-02 Matthias Klose <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
