Re: Bug#163666: debian-policy: Unclear result with [arch] and |

[Guillem Jover]

Hi,

On Sat, 2008-07-05 at 17:09:48 -0700, Russ Allbery wrote:
> Bug#163666 against debian-policy points out that arch-specific build
> dependencies are unclearly specified in Policy currently in the presence
> of alternatives.  The current wording says:
> 
>  All fields that specify build-time relationships (`Build-Depends',
>  `Build-Depends-Indep', `Build-Conflicts' and `Build-Conflicts-Indep')
>  may be restricted to a certain set of architectures.  This is
>  indicated in brackets after each individual package name and the
>  optional version specification.  The brackets enclose a list of
>  Debian architecture names separated by whitespace.  Exclamation marks
>  may be prepended to each of the names.  (It is not permitted for some
>  names to be prepended with exclamation marks while others aren't.) If
>  the current Debian host architecture is not in this list and there
>  are no exclamation marks in the list, or it is in the list with a
>  prepended exclamation mark, the package name and the associated
>  version specification are ignored completely for the purposes of
>  defining the relationships.
> 
> The problem is that "ignored completely" is not well-specified in the
> presence of alternatives.

> What does dpkg actually implement?  In particular, how are the following
> cases handled?

It will discard any part that's not relevant for the current
architecture, and then the left relationships checked. Your usage of
satisfied confused me a bit, as I'd expect it to also depend on the
availability of those packages on that given architecture. Anyway in
your examples:

> - Is "foo [i386] | bar" satisfied on any alpha system, or are all non-i386
>   systems required to have bar?

On alpha that'd become: "bar".

> - Does "foo [i386] | bar [!i386]" work correctly (require foo on all i386
>   systems and bar on all other systems)?

On i386: "foo".
On !i386: "bar".

> - Similarly, does "foo [i386] | bar [amd64] | baz [!i386 !amd64]" work
>   correctly (require foo on i386, bar on amd64, and baz everywhere else)?

Yes.

> - What does "foo [i386] | bar [amd64]" mean on a powerpc system?  Is it
>   always satisfied or never satisfied?

On powerpc it should disappear, no dependency to check, so it would be
satisfied.

> - Is "foo [!i386] | bar [!amd64]" satisfied on any i386 system, or are
>   i386 systems required to have bar installed?  Does this reduce to "foo |
>   bar" on powerpc systems or to something else?

On i386: "bar".
On amd64: "foo".
On the rest: "foo | bar".

> These may all be different variations of the same question or may be
> different questions depending on how this is implemented internally.  If
> you have any ideas as to how to word what dpkg does, they would be
> gratefully accepted.

I guess explaining that non-relevant dependencies are discarded makes it
easier to understand?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#163666: debian-policy: Unclear result with [arch] and |

[Russ Allbery]

dpkg folks,

Bug#163666 against debian-policy points out that arch-specific build
dependencies are unclearly specified in Policy currently in the presence
of alternatives.  The current wording says:

 All fields that specify build-time relationships (`Build-Depends',
 `Build-Depends-Indep', `Build-Conflicts' and `Build-Conflicts-Indep')
 may be restricted to a certain set of architectures.  This is
 indicated in brackets after each individual package name and the
 optional version specification.  The brackets enclose a list of
 Debian architecture names separated by whitespace.  Exclamation marks
 may be prepended to each of the names.  (It is not permitted for some
 names to be prepended with exclamation marks while others aren't.) If
 the current Debian host architecture is not in this list and there
 are no exclamation marks in the list, or it is in the list with a
 prepended exclamation mark, the package name and the associated
 version specification are ignored completely for the purposes of
 defining the relationships.

The problem is that "ignored completely" is not well-specified in the
presence of alternatives.

What does dpkg actually implement?  In particular, how are the following
cases handled?

- Is "foo [i386] | bar" satisfied on any alpha system, or are all non-i386
  systems required to have bar?

- Does "foo [i386] | bar [!i386]" work correctly (require foo on all i386
  systems and bar on all other systems)?

- Similarly, does "foo [i386] | bar [amd64] | baz [!i386 !amd64]" work
  correctly (require foo on i386, bar on amd64, and baz everywhere else)?

- What does "foo [i386] | bar [amd64]" mean on a powerpc system?  Is it
  always satisfied or never satisfied?

- Is "foo [!i386] | bar [!amd64]" satisfied on any i386 system, or are
  i386 systems required to have bar installed?  Does this reduce to "foo |
  bar" on powerpc systems or to something else?

These may all be different variations of the same question or may be
different questions depending on how this is implemented internally.  If
you have any ideas as to how to word what dpkg does, they would be
gratefully accepted.

Thanks!

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.

[Russ Allbery]

Please check the following patch, which attempts to clarify how dpkg
diversions should be handled.  Once I started digging into this, the cases
looked more complex than I had expected.  I tried to add more language to
explain the whole situation on the grounds that if I found it confusing,
other people almost certainly also do.

diff --git a/policy.sgml b/policy.sgml
index 24c9072..0cd241a 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -10564,26 +10564,37 @@ install-info --quiet --remove 
/usr/share/info/foobar.info
supposing that a smailwrapper package wishes to
install a wrapper around /usr/sbin/smail:

-  if [ install = "$1"  ]; then
- dpkg-divert --package smailwrapper --add --rename \
---divert /usr/sbin/smail.real /usr/sbin/smail
-  fi
-Testing $1 is necessary so that the script
-   doesn't try to add the diversion again when
-   smailwrapper is upgraded.  The --package
-   smailwrapper ensures that smailwrapper's
-   copy of /usr/sbin/smail can bypass the diversion and
-   get installed as the true version.
+   dpkg-divert --package smailwrapper --add --rename \
+  --divert /usr/sbin/smail.real /usr/sbin/smail
+The --package smailwrapper ensures that
+   smailwrapper's copy of /usr/sbin/smail
+   can bypass the diversion and get installed as the true version.
+   It's safe to add the diversion unconditionally on upgrades since
+   it will be left unchanged if it already exists, but
+   dpkg-divert will display a message.  To suppress that
+   message, make the command conditional on the version from which
+   the package is being upgraded:
+   
+   if [ upgrade != "$1" ] || dpkg --compare-versions "$2" lt 1.0-2; then
+  dpkg-divert --package smailwrapper --add --rename \
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+   fi
+where 1.0-2 is the version at which the
+   diversion was first added to the package.  Running the command
+   during abort-upgrade is pointless but harmless.
   
 
   
The postrm has to do the reverse:

-  if [ remove = "$1" ]; then
+  if [ remove = "$1" -o abort-install = "$1" -o disappear = "$1" ]; then
  dpkg-divert --package smailwrapper --remove --rename \
 --divert /usr/sbin/smail.real /usr/sbin/smail
   fi
-   
+The postrm should not remove the diversion on upgrades
+   both because there's no reason to remove the diversion only to
+   immediately re-add it and since the postrm of the old package is
+   run after unpacking so the removal of the diversion will fail.
   
 
   

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Triggers and package configuration

[Max Bowsher]

Hi, I'm trying to create a package using triggers, and running into a
problem - perhaps someone here can point me in the right direction.

I'm trying to make a package that will add an organization self-signed
SSL certificate to all the system JVMs's trusted certs - and use
triggers to allow it to notice the installation of a new JVM and take
appropriate action. So, I've registered an "interest /usr/lib/jvm"
trigger and that works fine, when "dpkg -i" is used.

However, when apt installs a package, it uses "dpkg --unpack", and this
is causing my customization package's trigger to run whilst the incoming
JVM package is unpacked but not configured.

Is there anything I can do to defer my triggered logic until after
configuration happens?

Max.



signature.asc
Description: OpenPGP digital signature