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

Re: Draft spec for new dpkg "triggers" feature

Florian Weimer writes ("Re: Draft spec for new dpkg "triggers" feature"):
> [Ian Jackson:]
> > To restore a package in state `triggered' to `installed', dpkg will
> > run the postinst script:
> >    postinst triggered "<trigger-name> <trigger-name> ..."
> Is this completely POSIX-conforming if there are many triggers?

You seem to be worried about command line argument length limits,
although I'm forced to read between the lines.  It would be more
helpful if you were more explicit.

I have two answers to that point:

1. There will obviously be a limit to how many trigger names can be
passed in this way.  If a package comes too close to this limit we may
have to consider offering a different way to pass this information, or
perhaps just truncating it.  As a workaround, some distinct triggers
could be merged.

2. That's irrelevant.  dpkg does not need to run on every
POSIX-confirming system.  It only has to run on reasonable free
systems.  If the command-line length limit is too severe then that is
a bug in the underlying system.

Other possibilities for passing this information seem to include:
 * writing it to a temporary file (what a palaver both for dpkg
   and for the maintainer script)
 * environment variables (messy and still subject to possibly small
   implementation limits)
 * not at all

Putting them in an argument means that maintainer scripts can do
    case "$1" in
          case " $2 " in *" /some/trigger/name "*) update-it;; esac
and the like.  Obviously it wants to be all in one argument so we have
room for adding more information later.


(CC to debian-devel and debian-policy removed.  Did you deliberately
fail to honour my Reply-To header or did something strip it out

Reply to: