Hi! On Fri, 2009-03-13 at 09:18:03 +0100, Raphael Hertzog wrote: > That looks almost right. I hope Guillem can confirm that it's ok for him > as well.
> On Fri, 13 Mar 2009, Norbert Preining wrote: > > We will have 3 different install-info: > > > > 1) /usr/sbin/install-info from dpkg > > this one will do: > > . if called with absolute path, warn the user to use > > /usr/bin/install-info Actually, if called with an absolute path, the warning should ask the caller to not use such absolute path (maybe as a side note, explain the rationale, because it's generally wrong, and in this case because it will stop working if using /usr/sbin/). > > . if called and there is no /usr/bin/install-info give a big fat > > warning and die. Or? > > Dying is not really an option. It might be legitimate that > /usr/bin/install-info is not here: because no info reader is installed. Right. Also I guess when warning we want to distinguish here the case a maintainer script is calling us, which then we want to explain that they should stop doing so, as this is handled by triggers now. And the case a user is calling us which we'd recommend them installing at least the install-info package and maybe an info-browser. Otherwise as there's no /usr/bin/install-info we'll not be able to give accurate info. > The Breaks: added to dpkg ensures that info browsers have the right > dependency on install-info. That's enough, there's no reason to die. Right. > > . Otherwise call /usr/bin/install-info "$@" > > 2) /usr/bin/install-info from install-info > > this one will do: > > . if called from within a maintainer script (! -z "$DPKG_RUNNING_VERSION") > > then simply warn that the package should be updated and do nothing Same as the new dpkg's install-info. > > . otherwise call simply ginstall-info "$@" (and maybe warn?) > Note: if we really wanted, we could avoid that intermediary wrapper and > have it in dpkg but that would mean that the "install-info" interface is > deprecated and that user are expected to use ginstall-info in the long > term. Well, I don't see why that'd be the case. The install-info package can always reclaim the correct path name in the future once we drop the wrapper from dpkg. Also no one should be using absolute paths anyway, and maintainer scripts are not expected to be calling it once the transition is started either. Remember install-info will just disappear at some point from essential, so anyone unconditionally calling it would be as broken. And we are not going to be advertising to use ginstall-info directly. I still think two different wrappers is a bit overkill. Both will need to implement mostly the same behaviour, as dpkg's install-info cannot assume that the install-info package is installed. > If the official upstream name is install-info, then we should rather keep > that intermediary wrapper. It is, but for example automake generated Makefiles have been ignoring Debian's install-info for long time, and will not fail if it's not present either, and it is also mostly only useful if you are installing to a system directory (which implies a root invokation). Anyway I think I'd prefer only one install-info in /usr/sbin/, but would not mind the other one in /usr/bin/. In the latter case both should be mostly identical IMO, either hardlinks in dpkg, or the same source code duped in both packages (dpkg and install-info). regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org