Hi, Francesco P. Lovergine wrote:
> Those issues will be solved during squeeze release > anyway when tcl/tk will move to 8.5 default. What can I do to help with this? > On Fri, Feb 20, 2009 at 01:02:26AM +0800, darren wrote: >> please provide an 8.5 version of tcl and tk metapackage. >> related bugs #503113 and #515325 in which user reported that >> gitk should depend on tk instead of tk8.5, [...] > The current Tcl/Tk policy is quite clear about that. > Packages should depend on > > tk (>= 8.5) > > iff the minimal version is _required_. Having a working > but ugly interface does not justify a strict versioning > in this case. The aim of this approach is allowing to > migrate tk default version to 8.6 or what ever without > having to rebuild all rdepends to have something like > > tk8.5 | tk8.6 | ... > > for ever as in the past. FWIW I think this policy is problematic. In a package like gitk (which requires tk 8.4 or greater), it would be nice to depend on tk (>= 8.4), use wish, and be done with it. But in the current situation, that is not really right, since the user might have both current tk (which pulls in tk8.4) and tk8.3 installed and have chosen to use tk8.3 to provide wish. With the current policy, what can a packager do? - Use wish-default instead of wish: This would be reliable but cheats the user out of new tk features. - Depend on wish and use wish: That dependency would appear to be satisfied by tk8.3, which is a no-go. - Breaks: tk8.3: But gitk _doesn’t_ break tk8.3, and using this strategy in general ruins the advantage of allowing some packages to use one tk version and others to use another. No, there are only two reasonable options for a packager I can see: - The old way (Depends: tk8.4 | tk8.5 | tk8.6 | ... and run $(which wish8.6 wish8.5 wish8.4 | head -1)). This does not let the user choose a tk version, and it requires updating dependencies each time a new tk version comes out. - Depends on tk (>= 8.4) and use wish. By default, wish will point to wish-default, which works. The sysadmin might set wish to point to wish8.3, in which case gitk will complain and the user can put a symbolic link to the correct wish on his $PATH. The sysadmin might set wish to point to wish8.5 or wish8.6, in which case, all the better. This is ugly. I’d rather have /usr/bin/wish be a wrapper script that runs the most recent wish version installed. This is almost always what the user wants. If a new tk version breaks old software, it can use Breaks: and then we should fix the bug! Just my two cents, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100217014349.ga3...@progeny.tock
