Semantic change for dpkg triggers?
Raphael Hertzog
I am considering changing the default behaviour of dpkg triggers. [1]
Currently when a package activates a trigger (except if it uses
dpkg-trigger directly with the --no-await option, and that is a minority
of cases), the trigerring package ends up in "triggers-awaited" status
and it doesn't satisfy dependencies.
This tends to be not needed and requires trigger processing sooner than
what's really required in many cases. Thus I am considering to change
this: the triggering package would directly go to the installed status
(the old behaviour could be kept if the package implementing the trigger
switched to another trigger directive named "interest-crucial" for example
instead of the usual "interest").
My question is thus: are there triggers currently in use where this
relaxed behaviour would be wrong? Or more simply are there packages which
are really not working before the processing of their awaited triggers?
Alternatively we could also discuss whether it would make sense
to change the meaning of the triggers-awaited status to something where
it would be enough to satisfy dependencies.
Thank you for your feedback.
Cheers,
[1] Initial proposal here: http://lists.debian.org/debian-dpkg/2011/05/msg00075.html
For more background information, you can read my recent blog post:
http://raphaelhertzog.com/2011/05/30/trying-to-make-dpkg-triggers-more-useful-and-less-painful/
and also the
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110530152...@rivendell.home.ouaza.com
Joey Hess
> My question is thus: are there triggers currently in use where this
> relaxed behaviour would be wrong? Or more simply are there packages which
> are really not working before the processing of their awaited triggers?
python-support seems to need that; python does not see files in
/usr/share/pyshared/, so until update-python-modules has run, a python
module cannot be used.
ghc libraries could need it, if any package depends on such a library
being available to be compiled against at installation time. I don't
know if any packages use ghc libraries like this currently, but I have
considered writing one that does, if I ever found the time to rewrite
ikiwiki in haskell.
--
see shy jo
Raphael Hertzog
> Raphael Hertzog wrote:
> > My question is thus: are there triggers currently in use where this
> > relaxed behaviour would be wrong? Or more simply are there packages which
> > are really not working before the processing of their awaited triggers?
>
> python-support seems to need that; python does not see files in
> /usr/share/pyshared/, so until update-python-modules has run, a python
> module cannot be used.
That's true but that's precisely why python-support is not using
triggers for this part of the task, they are processed too late
and keep stuff broken for far too long.
The python-support trigger is used for the non-important part (I think
it's the same but for non-standard python versions), and it's actually
activated by /usr/sbin/update-python-modules with the --no-await
option.
> ghc libraries could need it, if any package depends on such a library
> being available to be compiled against at installation time. I don't
> know if any packages use ghc libraries like this currently, but I have
> considered writing one that does, if I ever found the time to rewrite
> ikiwiki in haskell.
I don't know anything about Haskell. What does the trigger do? Is it some
sort of non-optional byte-compilation?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011053016...@rivendell.home.ouaza.com
Joey Hess
> I don't know anything about Haskell. What does the trigger do? Is it some
> sort of non-optional byte-compilation?
It makes the cabal package manager aware of the package installed by the
dpkg package manager, iirc.
--
see shy jo
Ian Jackson
> I am considering changing the default behaviour of dpkg triggers. [1]
> Currently when a package activates a trigger (except if it uses
> dpkg-trigger directly with the --no-await option, and that is a minority
> of cases), the trigerring package ends up in "triggers-awaited" status
> and it doesn't satisfy dependencies.
>
> This tends to be not needed and requires trigger processing sooner than
> what's really required in many cases. Thus I am considering to change
> this: the triggering package would directly go to the installed status
> (the old behaviour could be kept if the package implementing the trigger
> switched to another trigger directive named "interest-crucial" for example
> instead of the usual "interest").
In general, the reason for this rule about satisfying dependencies is
that a triggering package may well not be functional at all until the
trigger is run. For example, if the triggering package T needs to be
registered with the interested package I, a package D which depends on
T may find that T does not work - and D's postinst may fail due to T
being broken.
But I can see that there might be a need for a less-restrictive
trigger, where the functionality which will be provided by trigger
processing is not crucial. But it seems to me that whether the
functionality is crucial is at least as much a property of the
triggering package, not the interested package.
If a new behaviour is needed, it should have a new name. Otherwise
you break existing packages.
So I would suggest:
* New trigger directive "trigger-noawait", works like
dpkg-trigger --no-await
But we do also need a way to do this for file triggers:
* New trigger directive "interest-filenoawait" which has the
following semantics:
- when triggered explicitly by name by a triggering package,
the triggering package awaits the trigger unless the
triggering package specifies --no-await
- when triggered implicitly by installation of a file, the
triggering package does not await the trigger
> My question is thus: are there triggers currently in use where this
> relaxed behaviour would be wrong? Or more simply are there packages which
> are really not working before the processing of their awaited triggers?
I haven't done a survey but I would expect there to be some.
> Alternatively we could also discuss whether it would make sense
> to change the meaning of the triggers-awaited status to something where
> it would be enough to satisfy dependencies.
That would be wrong IMO. If triggering without impeding dependencies
is required, simply going straight to "installed" is correct.
Ian.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/19943.33579....@chiark.greenend.org.uk
Raphael Hertzog
On Thu, 02 Jun 2011, Ian Jackson wrote:
> If a new behaviour is needed, it should have a new name. Otherwise
> you break existing packages.
I know this. This is precisely why I'm asking the question of which
packages require this behaviour. If none or very few require it, I might
consider doing the change with the current name and provide new names
for the old behaviour.
Just for reference, if you review my patch at
http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=commitdiff;h=c98b69d76f78114afd344b9dc0aef47c6f3fe00b
...
> So I would suggest:
>
> * New trigger directive "trigger-noawait", works like
> dpkg-trigger --no-await
...you will notice this is called "activate-noawait"
> But we do also need a way to do this for file triggers:
>
> * New trigger directive "interest-filenoawait" which has the
> following semantics:
> - when triggered explicitly by name by a triggering package,
> the triggering package awaits the trigger unless the
> triggering package specifies --no-await
> - when triggered implicitly by installation of a file, the
> triggering package does not await the trigger
this is called "interest-noawait" except that I have made no difference
when the file trigger is explicitly called by dpkg-trigger. I don't see a
good reason for this.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110603065...@rivendell.home.ouaza.com
Phillip Susi
> In general, the reason for this rule about satisfying dependencies is
> that a triggering package may well not be functional at all until the
> trigger is run. For example, if the triggering package T needs to be
> registered with the interested package I, a package D which depends on
> T may find that T does not work - and D's postinst may fail due to T
> being broken.
If postinst depends on the package, then it should be a pre-depend, not
a depend, shouldn't it?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve Langasek
> On 6/2/2011 8:33 AM, Ian Jackson wrote:
> >In general, the reason for this rule about satisfying dependencies is
> >that a triggering package may well not be functional at all until the
> >trigger is run. For example, if the triggering package T needs to be
> >registered with the interested package I, a package D which depends on
> >T may find that T does not work - and D's postinst may fail due to T
> >being broken.
> If postinst depends on the package, then it should be a pre-depend,
> not a depend, shouldn't it?
Absolutely not.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org