Bug#250632: Incorrectly identifies menu-methods as needing +x
On Mon, May 24, 2004 at 11:42:33AM +0200, Jeroen van Wolffelaar wrote:
> On Mon, May 24, 2004 at 07:10:04PM +1000, Matthew Palmer wrote:
> >
> > I thought so at first -- to point that I was most of the way through a bug
> > report for menu and debhelper. But it does actually make some measure of
> > sense, after a bit of thought. If the package in the unpacked state, you
> > don't necessarily want it having menu entries created for it. This would
> > mostly happen in the case where multiple update-menus using packages are
> > unpacked in the one install run. Consider that the menu-methods script
> > might use something in the same package that needs to be configured to work
> > -- or, worse, needs something from another package that needs to be
> > configured. If the script is only made executable on postinst, then
> > update-menus runs while the package is unpacked but not configured won't run
> > the new script.
> >
> > Hmm, this could be an argument for not shipping anything +x until
> > postinst... I think I'll hold off filing the bugs for that, though...
It is a problem only with programs called from maintainer scripts
that do not belong to a depended upon packages, which is obviously a rare
occurence, since normally you should add a dependency.
For example, if you call debconf in your maintainer script, you should
depend on debconf. dpkg will configure debconf before running your
postinst so you do not risk to execute debconf before it is configured.
update-menus is an emulation of dpkg hooks and so is an exception to the
above rule. update-menus is run by postinst/postrm scripts but run
asynchronously and execute all the executable scripts it found.
As a reference why you cannot use non-configured packages:
Policy 7.2:
A `Depends' field takes effect _only_ when a package is to be
configured. It does not prevent a package being on the system in an
unconfigured state while its dependencies are unsatisfied, and it is
possible to replace a package whose dependencies are satisfied and
which is properly installed with a different version whose
dependencies are not and cannot be satisfied;
This imply that a binary might be installed but not some libraries it
is linked to not yet unpacked, and so will crash. And doing so _is_ a
bug.
> The greater issue is that it simply is how Debian works -- that packages
> in unpacked-but-not-yet-configured state simply might not work. That's
> valid for a lot of stuff. I don't think it's up to the menu policy to
> have a -- very partial in scope -- workaround for this issue.
I beg to differ. The scripts in question are _configuration files_.
The general Debian policy mandate that such scripts are not removed
when packages (window-managers here) are removed but not purged. To
that effect, executable scripts must be prevented to be run when the
package is removed. Usually it is implemented by a simple
test -x $DAEMON || exit 0
in the scripts. Unfortunately doing so for update-menus would create a
race-condition since it run asynchronously, and so the current solution
was designed.
That imply postrm scripts must
1) chmod -x the menu method if called with remove
2) remove it if called with purge
To make menu work again after the package is installed back, postinst
must chmod +x the menu method.
So the snippets in the maintainer scripts are really to allow for
package removal/reinstallation not to work around the configuration problem.
It appears that not shipping the maintainer scripts executable does fix
the configuration problem due to snippets above at a very low cost.
Truely, most menu-methods does not call external programs, let alone
non-essential program, so most of them should be fine if shipped +x in
the package. However, joeyh do not want debhelper to assume it is the
case.
To summary, it is seldom a bug to ship menu-methods +x, but it is never
a bug to ship them -x in the package.
> Really, changing permissions in postinst _is_ a kludge, and in this
> case, it's only to prevent running _via the menu_ of programs that are
> half-installed, but doesn't prevent running them via command-line and
This statement is not true, changing permission in postinst is not
done for that purpose as explained above.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: