Semantic change for dpkg triggers?
 

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.

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

Semantic change for dpkg triggers?
 

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.

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

Semantic change for dpkg triggers?
 

On 05/30/2011 06:17 PM, Joey Hess wrote:
> 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.

python-support should be removed at some point in the future.

--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DE3C630.7090400@bzed.de">http://lists.debian.org/4DE3C630.7090400@bzed.de

Semantic change for dpkg triggers?
 

On Mon, 30 May 2011, Joey Hess wrote:
> 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-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110530164827.GA2397@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110530164827.GA2397@rivendell.home.ouaza.com

Semantic change for dpkg triggers?
 

On Mon, 30 May 2011, Joey Hess wrote:
> 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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110530164827.GA2397@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110530164827.GA2397@rivendell.home.ouaza.com

Semantic change for dpkg triggers?
 

Raphael Hertzog wrote:
> 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

Semantic change for dpkg triggers?
 

Raphael Hertzog wrote:
> 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

Semantic change for dpkg triggers?
 

Raphael Hertzog writes ("Semantic change for dpkg triggers?"):
> 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-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19943.33579.996365.262523@chiark.greenend.org.uk"> http://lists.debian.org/19943.33579.996365.262523@chiark.greenend.org.uk

Semantic change for dpkg triggers?
 

Raphael Hertzog writes ("Semantic change for dpkg triggers?"):
> 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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19943.33579.996365.262523@chiark.greenend.org.uk"> http://lists.debian.org/19943.33579.996365.262523@chiark.greenend.org.uk

Semantic change for dpkg triggers?
 

Hi,

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=c98b69d76f78114afd344b9dc0 aef47c6f3fe00b
...

> 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-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110603065709.GI13100@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110603065709.GI13100@rivendell.home.ouaza.com