Ben Gertzfield <[EMAIL PROTECTED]> writes: > Version 1.1.5 of both GTK+ and GLib have just been released. I have > received complaints about packages compiled against, say GTK+ 1.1.2, > breaking as soon as 1.1.3 is installed. Should I: > > 1) make the source and binary names for the new packages like gtk+1.1.5 > and glib1.1.5, changing the source and binary package names each time > a new developmental upstream release comes out > > or > > 2) say "screw it" and make the shlibs for GTK+ and GLib be (=1.1.5-1), > updating the exact dependancy each time a new package is released.
Nononononononnononon; don't you dare. dpkg doesn't do reverse dependency checking[1]; if I have say foo installed which depends on libgtk1.1 (= 1.1.5-1), it'll happily let me install libgtk1.1 1.1.6-1, silently breaking foo. (1) is the only option. If we limit the number of packages compiled with gtk1.1 (as opposed to gtk1), it won't be that big a deal, IMHO. (Space is not an issue, if it were, we would presumably get rid of iraf, picons, timidity patches or something similar first). [1] Jason and other members of the Apt Propaganda Team are kindly requested to take their comments on this to /dev/null :-P Even ignoring the lack of rev dep checking, (1) is the Right solution anyway. -- James
