Re: New unstable GTK+/GLib packages' names -- seeking advice
Ben Gertzfield <che@debian.org> 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
Reply to: