Re: Transition from dpkg to GNU install-info
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
Reply to: