[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Undeclared dependencies on menu



On Wed, 13 May 1998, Joey Hess wrote:

> Bob Hilliard wrote:
> >      While testing the install disks v2.0.6, menu failed to install
> > due to unsatisfied dependencies.  (This is the subject of another
> > message). 
> > 
> >      Since menu was not configured, man-db, psmisc, bc, and dc could not
> > be configured because the postinst called update-menu, resulting in
> > the following error message:
> > 
> > : update-menus: error in loading shared libraries
> > : libstdc++.so.2.7.2: cannot open shared object file: No such file or
> > : directory
> > 
> >      None of these packages declare a dependency on menu.  I believe
> > that policy should require that a package must declare a dependency on
> > any non-required utility used by the maintainer scripts, or the
> > scripts should be designed not to fail if such a utility is not
> > available.  
> > 
> >      Should a bug be filed against these four packages?  I am sure
> > there are many other packages that use update-menu in their postinsts
> > and do not declare a dependency on menu.
> 
> Hundreds of packages use menu. The calls to menu are guarded by a test to
> see if menu is installed:
> 
> if [ -x /usr/bin/update-menus ]; then
> 	/usr/bin/update-menus
> fi
> 
> Anything using such a test does not have to depend on the command inside the
> if statement, as it will install just fine without it.

But it may not install 'just fine' if the command is in an unconfigured
state.

> You have run into a bug in menu (if it is insdeed missing some dependancy)
> or in dselect (if it's configuring things in the wrong order (likely)), but
> this is not aq bug in the hundred of packages that use menu.

The package that uses update-menus in the postinst without depending on
menu may be configured by dselect before menu, if both packages are
upgraded in the same run. I wonder what happens if you do that. I wouldn't
call it a bug in dselect, since it behaves like it's designed: if two
packages don't Depend: on each other, it doesn't matter in which order
they are configured.

Remco



--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: