Bug#447611: update-initramfs triggerisation
maximilian attems <[EMAIL PROTECTED]> writes: >> > > +binary-install/initramfs-tools:: >> > > +install -m 644 -o 0 -g 0 debian/initramfs-tools.triggers \ >> > > +debian/initramfs-tools/DEBIAN/triggers >> > >> > no i-t uses cdbs, >> > please add to debian/initramfs-tools.install >> > but maybe i misread and there is no cdbs support for that yet?? >> >> Stuffing files into DEBIAN/ with .install seemed a bit wrong to me, >> and I thought this approach with a hook was better. >> >> In the future I imagine debhelper will copy .triggers into >> the right place itself. > > debhelper does it according to joeyh, > i haven't looked yet at how i'd have to invoke it. http://packages.qa.debian.org/d/debhelper/news/20071022T181701Z.html -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> thanks for your quick reply.
NP
> On Tue, 23 Oct 2007, Ian Jackson wrote:
> > Changes to debian/changelog always tend to get rejected if you apply a
> > patch to a different version because the context is the previous
> > version which contains the previous version number.
>
> yeah it is a primitive versioning system.
Annoying, isn't it. It's nice to see some efforts towards improving
the situation ...
> > test(1) has really strange argument parsing, [...]
>
> ok thanks for the lesson.
> never the less i'd prefer to have more readable code,
> then to take into account crazy non posix sh.
> update-initramfs is anyway linux specific.
I think you misunderstood me. I'm not saying that failing to use
"x$..." is nonportable. I'm saying that it can be ambiguous in the
sense that even the test(1) we're actually using (in practice, the
builtins in bash and dash) may sometimes get it wrong, where `wrong'
means `not what we intended'.
My example was that if you write
test '(' "$var" ')'
then it will go wrong when var='=' because it is interpreted as if you
had meant
test "$a" = "$b"
with a='(' and b=')'.
The exact circumstances in which the expression can be ambiguous are
very complicated. The best approach therefore is to prefix the
arguments to these kind of comparisons with `x' so that they cannot be
misinterpreted by test as operators. Ie the solution is to write
test "x$var" != x
which can never look like anything except a comparison because none of
test's operators or syntax start with an x.
If we write our scripts this way all of the time then there is no
possibility that someone who later makes the code more complicated by
adding additional clauses to the test, or introduces additional
possible values for the inputs, will cause it to break. And we get
into the habit of writing code which is always correct, without having
to prove each time that the particular construction we use can never
be misunderstood by test(1).
This area is a subset of the principle of argument unparsing - that
is, how to pass arbitrary arguments to a program without possibility
of misunderstanding.
In general if you see constructions of the form
command-name "$inputvariable" ...
you should be suspicious. What if inputvariable contains a string
which is meaningful to command-name as an option ? Hence
command-name -- "$inputvariable" ...
et al.
> > In the future I imagine debhelper will copy .triggers into
> > the right place itself.
>
> debhelper does it according to joeyh,
> i haven't looked yet at how i'd have to invoke it.
Oh, has he added that already ? The version I had to hand didn't seem
to but perhaps I misread the documentation or was reading the wrong
version.
> i'll see to push a variant in git next days,
> may ping you for review..
Sure.
> so that i can upload it promptly with new dpkg.
Excellent. (As I said, though, I think there is no need to wait.)
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
thanks for your quick reply.
On Tue, 23 Oct 2007, Ian Jackson wrote:
[snipp ubuntu explanation]
> I obviously thought it would be better to send you the patch we were
> actually using rather than some `special' version which we hadn't
> tested. You are of course free to remove tests of this kind, but in
> the general that just makes a bit more work for the Ubuntu developer
> who next has to merge initramfs-tools from Debian.
curious on review :)
> Changes to debian/changelog always tend to get rejected if you apply a
> patch to a different version because the context is the previous
> version which contains the previous version number.
yeah it is a primitive versioning system.
> test(1) has really strange argument parsing, which is sometimes
> ambiguous. Prefixing unknown input strings with x avoids accidentally
> treating those strings as operators or syntactic elements.
>
> For example, consider:
> test '(' '=' ')'
>
> Is this
> test '(' EXPR ')' where EXPR is '=', equivalent to -n '='
> or
> test A '=' Bwhere A is '(' and B is ')'
> ?
>
> It may be possible in particular cases to show that the problem cannot
> arise. SuSv3 has a crazy set of explicit rules which only go as far
> as up to 4 arguments (and so answers my question above). So both to
> avoid having to do a detailed analysis of test(1)'s argument parsing
> and of the possible input strings, and as a matter of good programming
> habit, it is better to write code the way it will always work (even if
> a subsequent programmer makes it more complex).
ok thanks for the lesson.
never the less i'd prefer to have more readable code,
then to take into account crazy non posix sh.
update-initramfs is anyway linux specific.
> In your version the "..." around `triggered' are superfluous. When I
> see that in a shell script I start to wonder whether the author knows
> the proper sh quoting rules. I trust that you do :-) but I would
> suggest avoiding idioms which tend to undermine the reader's
> confidence in the author.
ack
> > > +interest update-initramfs
> > "interest" ???
>
> `interest' is the directive name used in the triggers file to specify
> that this package needs to know about activations of the named
> trigger.
ok, thanks i'll add your comment.
> I chose the explicit trigger name `update-initramfs' since it seemed
> like an obvious choice. The guideance in the triggers spec (which I
> wrote, of course) says that it's often good to choose a command or
> package name and the command name seems like a good choice here.
>
> Do you have a different view ?
no,
the meaning of the keywoard "interest" is new to me.
> > > +binary-install/initramfs-tools::
> > > + install -m 644 -o 0 -g 0 debian/initramfs-tools.triggers \
> > > + debian/initramfs-tools/DEBIAN/triggers
> >
> > no i-t uses cdbs,
> > please add to debian/initramfs-tools.install
> > but maybe i misread and there is no cdbs support for that yet??
>
> Stuffing files into DEBIAN/ with .install seemed a bit wrong to me,
> and I thought this approach with a hook was better.
>
> In the future I imagine debhelper will copy .triggers into
> the right place itself.
debhelper does it according to joeyh,
i haven't looked yet at how i'd have to invoke it.
> I agree that this isn't the best style. One reason why I did it this
> way because I wanted to be sure that it did only and exactly what I
> intended it to. Another way of looking at it is that I regarded
> myself as wrapping update-initramfs. Obviously since update-initramfs
> is a script this could be done in code at the top of the script.
i see.
> > you may want to checkout latest git
> > git clone git://git.debian.org/git/kernel/initramfs-tools.git
>
> Would you like me to prepare a new patch based on your comments ?
no need,
patch is explicit enough.
i'll see to push a variant in git next days,
may ping you for review..
so that i can upload it promptly with new dpkg.
amicalement
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> hmm the relevant bug reports didn't get cc'ed to dpkg speaking of
> #447609
You mean this comment:
Couldn't file triggers be used, so ldconfig is triggered after any
package installs a library file? That's much more how I expected
triggers to be used, rather than needing an ugly ldconfig wrapper. I
think it also addresses drow's point about libraries in nonstandard
locations, since those packages could just run ldconfig as usual.
Meanwhile, packages installing libraries to standard locations could
stop calling ldconfig.
?
That's about ldconfig. It doesn't really make sense for
update-initramfs because the set of files which might need to activate
the trigger is all of the files which are copied into the initramfs.
The resulting list is (a) large, (b) hard to compute and (c) not
fixed.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
maximilian attems writes ("Re: Bug#447611: update-initramfs
triggerisation"):
> [stuff]
Thanks for looking at my patch.
> > + dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~'
> > +then
>
> ubuntu specific, would with high probab trigger on the wrong versions,
> also why is this needed?
> has there been a buggy dpkg trigger support!?
There was indeed a buggy dpkg trigger support version in some versions
of Ubuntu gutsy before it was released. Early in the release cycle of
a particular Ubuntu version many features are thrown into the Ubuntu
archive in a fairly ill-tested state - much more so than you would
typically do in Debian unstable.
So it shouldn't be seen as alarming or unusual that some bugs were in
the Ubuntu archive version at that stage, any more than it would be
alarming or unusual for a Debian developer to locally try out buggy
code, or share it with co-developers eg via experimental, while doing
pre-sid testing.
To be honest I don't have complete records of which versions were
buggy in the relevant way. That test is harmless in Debian because
none of the buggy versions were ever in Debian, and all
trigger-supporting versions in Debian will have a higher version
number. (We're not going to be backporting this large change, I
assume.)
At the time when I wrote the patch, that test served to protect Ubuntu
testers and developers who had the buggy dpkg from the consequences of
the bug. Using that particular syntax (with the ~~) also meant that I
was able to test the effect using some private versions I had built
locally without editing the version string just before upload (which
is obviously error-prone).
I obviously thought it would be better to send you the patch we were
actually using rather than some `special' version which we hadn't
tested. You are of course free to remove tests of this kind, but in
the general that just makes a bit more work for the Ubuntu developer
who next has to merge initramfs-tools from Debian.
In this particular case since the buggy dpkg existed only in early
versions of Ubuntu gutsy, I think this test has served its purpose and
can be discarded from Ubuntu as well as Debian.
> need to get a deeper look in git-dch as debian changelog only generates
> conflicts, better snipped for now also as ubuntu specific:
> patching file debian/changelog
> Hunk #1 FAILED at 1.
> 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
Changes to debian/changelog always tend to get rejected if you apply a
patch to a different version because the context is the previous
version which contains the previous version number.
> > +if [ "x$1" != xtriggered ] && \
>
> if [ "$1" != "triggered" ] && \
>
> seems more readable, don't know why the oldstyle x$string = string
> remains in usage?
test(1) has really strange argument parsing, which is sometimes
ambiguous. Prefixing unknown input strings with x avoids accidentally
treating those strings as operators or syntactic elements.
For example, consider:
test '(' '=' ')'
Is this
test '(' EXPR ')' where EXPR is '=', equivalent to -n '='
or
test A '=' Bwhere A is '(' and B is ')'
?
It may be possible in particular cases to show that the problem cannot
arise. SuSv3 has a crazy set of explicit rules which only go as far
as up to 4 arguments (and so answers my question above). So both to
avoid having to do a detailed analysis of test(1)'s argument parsing
and of the possible input strings, and as a matter of good programming
habit, it is better to write code the way it will always work (even if
a subsequent programmer makes it more complex).
In your version the "..." around `triggered' are superfluous. When I
see that in a shell script I start to wonder whether the author knows
the proper sh quoting rules. I trust that you do :-) but I would
suggest avoiding idioms which tend to undermine the reader's
confidence in the author.
> > update-initramfs -u
> > + # ... this activates the trigger, if triggers are working
>
> please comment before command.
Sorry, I evidently didn't look down far enough to see your existing
coding style, which I should of course have copied.
> > +interest update-initramfs
> "interest" ???
`interest' is the directive name used in the triggers file to specify
that this package needs to know about activations of the named
trigger.
I chose the explicit trigger name `update-initramfs' since it seemed
like an obvious choice. The guideance in the triggers spec (which I
wrote, of course) says that it's often good to choose a command or
package name and the command name seems like a good c
Bug#447611: update-initramfs triggerisation
On Tue, Oct 23, 2007 at 12:25:10PM +0100, Ian Jackson wrote:
> maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> > it is a prerequisite, until not merged i have zero evidence that the
> > interface may not have changed. afais on dpkg devel joeyh raised
> > good critics on how the trigger support is done.
>
> The only message I can find recently from Joey Hess on debian-dpkg
> regarding triggers is this one:
> http://lists.debian.org/debian-dpkg/2007/10/msg00047.html
> in which he seems keen. Where should I be looking, please ?
hmm the relevant bug reports didn't get cc'ed to dpkg speaking of
#447609
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> it is a prerequisite, until not merged i have zero evidence that the
> interface may not have changed. afais on dpkg devel joeyh raised
> good critics on how the trigger support is done.
The only message I can find recently from Joey Hess on debian-dpkg
regarding triggers is this one:
http://lists.debian.org/debian-dpkg/2007/10/msg00047.html
in which he seems keen. Where should I be looking, please ?
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
Joey Hess writes ("Re: Bug#447611: update-initramfs triggerisation"):
> Ian Jackson wrote:
> Content-Description: message body text
> > + && test x"$DPKG_MAINTSCRIPT_PACKAGE" != x \
>
> I take it that this is a magic flag variable set by dpkg when running a
> postinst?
Yes. This is a new feature introduced in the triggers patch, so I'm
afraid you can't rely on it yet in general.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
On Tue, Oct 23, 2007 at 01:45:46AM -0700, Steve Langasek wrote: > On Mon, Oct 22, 2007 at 06:12:44PM +0200, maximilian attems wrote: > > i'm following dpkg git, once this cool feature is merged, > > i'm happy to apply a patch using it. i didn't see it merged in > > the master tree yet. as i didn't follow the dpkg discsussions > > i don't know current status. > > Why should that be a prerequisite for merging these changes for > initramfs-tools? Reducing the diff between the Debian and Ubuntu packages > of initramfs-tools will make it easier to pass bugfixes between the two > distros for this package, and I don't see any reason to think this code will > make initramfs-tools less maintainable, so it seems like a good idea to me > to merge this change even if it's not yet useful in Debian. it is a prerequisite, until not merged i have zero evidence that the interface may not have changed. afais on dpkg devel joeyh raised good critics on how the trigger support is done. i agree that i like to keep the diff small and current shape of initramfs-tools would be cool for a merge in the next weeks. > > > + dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~' > > > +then > > ubuntu specific, would with high probab trigger on the wrong versions, > > also why is this needed? > > but the previous bit of code says that this only fires when the maintainer > script is called with "trigger" as the first argument. As there aren't any > older versions of dpkg in Debian that will ever call the maintainer scripts > this way, that seems reasonable to me? ok > Hmm, installing files into the DEBIAN/ directory using dh_install -- eew? > :-) > > Anyway, Joey's solution is better. yup, what's the invocation? > $ type test > test is a shell builtin > $ > > ? thanks for the lection, forgot that differs from current codingstyle, so i prefer the way i said and i don't like the getopt parsing ;) > I'm glad to hear it, I'd very much like to see Debian able to take advantage > of these speed-ups soon. :) full ack -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
On Mon, Oct 22, 2007 at 06:12:44PM +0200, maximilian attems wrote:
> i'm following dpkg git, once this cool feature is merged,
> i'm happy to apply a patch using it. i didn't see it merged in
> the master tree yet. as i didn't follow the dpkg discsussions
> i don't know current status.
Why should that be a prerequisite for merging these changes for
initramfs-tools? Reducing the diff between the Debian and Ubuntu packages
of initramfs-tools will make it easier to pass bugfixes between the two
distros for this package, and I don't see any reason to think this code will
make initramfs-tools less maintainable, so it seems like a good idea to me
to merge this change even if it's not yet useful in Debian.
> > + dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~'
> > +then
> ubuntu specific, would with high probab trigger on the wrong versions,
> also why is this needed?
but the previous bit of code says that this only fires when the maintainer
script is called with "trigger" as the first argument. As there aren't any
older versions of dpkg in Debian that will ever call the maintainer scripts
this way, that seems reasonable to me?
> has there been a buggy dpkg trigger support!?
Should that matter, given that any versions of dpkg with that bug are, as
you say, Ubuntu-specific? :)
> > diff -ruN ../orig/initramfs-tools-0.85eubuntu16/debian/rules
> > initramfs-tools-0.85eubuntu18/debian/rules
> > --- ../orig/initramfs-tools-0.85eubuntu16/debian/rules 2006-12-21
> > 23:32:07.0 +
> > +++ initramfs-tools-0.85eubuntu18/debian/rules 2007-08-16
> > 16:10:49.0 +0100
> > @@ -8,3 +8,7 @@
> > for x in `find scripts/ -maxdepth 1 -type d | tail -n+2`; do \
> > chmod -R +x $$x; \
> > done
> > +
> > +binary-install/initramfs-tools::
> > + install -m 644 -o 0 -g 0 debian/initramfs-tools.triggers \
> > + debian/initramfs-tools/DEBIAN/triggers
> no i-t uses cdbs,
> please add to debian/initramfs-tools.install
Hmm, installing files into the DEBIAN/ directory using dh_install -- eew?
:-)
Anyway, Joey's solution is better.
> but maybe i misread and there is no cdbs support for that yet??
> > diff -ruN ../orig/initramfs-tools-0.85eubuntu16/update-initramfs
> > initramfs-tools-0.85eubuntu18/update-initramfs
> > --- ../orig/initramfs-tools-0.85eubuntu16/update-initramfs 2007-04-10
> > 16:07:41.0 +0100
> > +++ initramfs-tools-0.85eubuntu18/update-initramfs 2007-08-16
> > 16:56:23.0 +0100
> > @@ -4,11 +4,24 @@
> > BOOTDIR=/boot
> > CONF=/etc/initramfs-tools/update-initramfs.conf
> > KPKGCONF=/etc/kernel-img.conf
> > +USETRIGGERS=true
> >
> > set -e
> >
> > [ -r ${CONF} ] && . ${CONF}
> >
> > +if$USETRIGGERS \
> > + && test x"$DPKG_MAINTSCRIPT_PACKAGE" != x \
> > + && test $# = 1 \
> > + && test x"$1" = x-u \
> > + && dpkg-trigger --check-supported 2>/dev/null
> why not using built-ins?
$ type test
test is a shell builtin
$
?
> don't get me wrong, i highly like the idea of that work
> and i'm happy to use it soon.
I'm glad to hear it, I'd very much like to see Debian able to take advantage
of these speed-ups soon. :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
On Mon, 22 Oct 2007, Joey Hess wrote: > maximilian attems wrote: > > no i-t uses cdbs, > > please add to debian/initramfs-tools.install > > but maybe i misread and there is no cdbs support for that yet?? > > More simply, debhelper supports it as of version 5.0.59. hmmm with all due respect cdbs is simpler to use. cool i'd hope cdbs uses debhelper support otherwise that bug needs to be cloned. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
Ian Jackson wrote: Content-Description: message body text > + && test x"$DPKG_MAINTSCRIPT_PACKAGE" != x \ I take it that this is a magic flag variable set by dpkg when running a postinst? J/C. -- see shy jo signature.asc Description: Digital signature
Bug#447611: update-initramfs triggerisation
maximilian attems wrote: > no i-t uses cdbs, > please add to debian/initramfs-tools.install > but maybe i misread and there is no cdbs support for that yet?? More simply, debhelper supports it as of version 5.0.59. -- see shy jo signature.asc Description: Digital signature
Bug#447611: update-initramfs triggerisation
tags 447611 -patch
stop
On Mon, 22 Oct 2007, Ian Jackson wrote:
> The attached patch triggerises the invocation of mkinitramfs by
> package maintainer scripts via update-initramfs.
thanks for the long description.
i'm following dpkg git, once this cool feature is merged,
i'm happy to apply a patch using it. i didn't see it merged in
the master tree yet. as i didn't follow the dpkg discsussions
i don't know current status.
> diff -ruN ../orig/initramfs-tools-0.85eubuntu16/debian/changelog
> initramfs-tools-0.85eubuntu18/debian/changelog
> --- ../orig/initramfs-tools-0.85eubuntu16/debian/changelog2007-07-31
> 06:31:15.0 +0100
> +++ initramfs-tools-0.85eubuntu18/debian/changelog2007-08-24
> 15:45:43.0 +0100
> @@ -1,3 +1,19 @@
> +initramfs-tools (0.85eubuntu18) gutsy; urgency=low
> +
> + * Use dpkg-trigger even in our own postinst, unless we're doing
> +trigger processing or the running dpkg version doesn't support
> +reflexive triggers. This reduces update-initramfs runs from two per
> +upgrade batch to one per batch.
> +
> + -- Ian Jackson <[EMAIL PROTECTED]> Fri, 24 Aug 2007 15:45:38 +0100
> +
> +initramfs-tools (0.85eubuntu17) gutsy; urgency=low
> +
> + * Use dpkg-trigger (if available and operational) to save on
> +calls to update-initramfs.
> +
> + -- Ian Jackson <[EMAIL PROTECTED]> Thu, 16 Aug 2007 16:03:52 +0100
> +
> initramfs-tools (0.85eubuntu16) gutsy; urgency=low
>
>* Load thermal modules on lpia as well. This may need to change in
need to get a deeper look in git-dch as debian changelog only generates
conflicts, better snipped for now also as ubuntu specific:
patching file debian/changelog
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
> diff -ruN
> ../orig/initramfs-tools-0.85eubuntu16/debian/initramfs-tools.postinst
> initramfs-tools-0.85eubuntu18/debian/initramfs-tools.postinst
> --- ../orig/initramfs-tools-0.85eubuntu16/debian/initramfs-tools.postinst
> 2006-12-21 23:32:07.0 +
> +++ initramfs-tools-0.85eubuntu18/debian/initramfs-tools.postinst
> 2007-08-24 15:45:02.0 +0100
> @@ -25,9 +25,16 @@
>
>
>
> -# Regenerate initramfs on upgrade
> -if [ "$1" = "configure" ] && [ -n "$2" ]; then
> +# Regenerate initramfs whenever we go to dpkg state `installed'
> +
> +if [ "x$1" != xtriggered ] && \
if [ "$1" != "triggered" ] && \
seems more readable, don't know why the oldstyle x$string = string
remains in usage?
> + dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~'
> +then
ubuntu specific, would with high probab trigger on the wrong versions,
also why is this needed?
has there been a buggy dpkg trigger support!?
> update-initramfs -u
> + # ... this activates the trigger, if triggers are working
please comment before command.
> +else
> + DPKG_MAINTSCRIPT_PACKAGE='' update-initramfs -u
> + # ... force it to actually happen
> fi
same
> #DEBHELPER#
> diff -ruN
> ../orig/initramfs-tools-0.85eubuntu16/debian/initramfs-tools.triggers
> initramfs-tools-0.85eubuntu18/debian/initramfs-tools.triggers
> --- ../orig/initramfs-tools-0.85eubuntu16/debian/initramfs-tools.triggers
> 1970-01-01 01:00:00.0 +0100
> +++ initramfs-tools-0.85eubuntu18/debian/initramfs-tools.triggers
> 2007-08-16 16:03:05.0 +0100
> @@ -0,0 +1 @@
> +interest update-initramfs
"interest" ???
please short comment above why this specific choice?
> diff -ruN ../orig/initramfs-tools-0.85eubuntu16/debian/rules
> initramfs-tools-0.85eubuntu18/debian/rules
> --- ../orig/initramfs-tools-0.85eubuntu16/debian/rules2006-12-21
> 23:32:07.0 +
> +++ initramfs-tools-0.85eubuntu18/debian/rules2007-08-16
> 16:10:49.0 +0100
> @@ -8,3 +8,7 @@
> for x in `find scripts/ -maxdepth 1 -type d | tail -n+2`; do \
> chmod -R +x $$x; \
> done
> +
> +binary-install/initramfs-tools::
> + install -m 644 -o 0 -g 0 debian/initramfs-tools.triggers \
> + debian/initramfs-tools/DEBIAN/triggers
no i-t uses cdbs,
please add to debian/initramfs-tools.install
but maybe i misread and there is no cdbs support for that yet??
> diff -ruN ../orig/initramfs-tools-0.85eubuntu16/update-initramfs
> initramfs-tools-0.85eubuntu18/update-initramfs
> --- ../orig/initramfs-tools-0.85eubuntu16/update-initramfs2007-04-10
> 16:07:41.0 +0100
> +++ initramfs-tools-0.85eubuntu18/update-initramfs2007-08-16
> 16:56:23.0 +0100
> @@ -4,11 +4,24 @@
> BOOTDIR=/boot
> CONF=/etc/initramfs-tools/update-initramfs.conf
> KPKGCONF=/etc/kernel-img.conf
> +USETRIGGERS=true
>
> set -e
>
> [ -r ${CONF} ] && . ${CONF}
>
> +if $USETRIGGERS \
> + && test x"$DPKG_MAINTSCRIPT_PACKAGE" != x \
> + && test $# = 1 \
> + && test x"$1" = x-u
Processed: Re: Bug#447611: update-initramfs triggerisation
Processing commands for [EMAIL PROTECTED]: > tags 447611 -patch Bug#447611: update-initramfs triggerisation Tags were: patch Tags removed: patch > stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447611: update-initramfs triggerisation
Source: initramfs-tools Version: 0.91b Severity: wishlist Tags: patch The attached patch triggerises the invocation of mkinitramfs by package maintainer scripts via update-initramfs. By `triggerises' I mean that the patch arranges for the formulaic update-initramfs invocations by maintainer scripts (eg of udev, kernel packages, etc.) to call dpkg-trigger instead of actually doing the work of update-initramfs and mkinitramfs. update-initramfs and hence mkinitramfs will be actually run out of initramfs-tools's postinst script during trigger processing. The consequence is that all of the initramfs updates during a dpkg run are deferred, and instead the update is done once at the end. This is achieved by new code in update-initramfs. This detects the formulaic invocation by a maintscript, and exec's dpkg-trigger instead (if the conditions are favourable). An alternative approach would be to change all of the packages not to call update-initramfs but instead to call a new script but this would involve a much more complicated and lengthy transition for no significant benefit. The patch is safe to use with a non-triggers-supporting dpkg and in all transitional states: where the trigger system is not properly set up yet, update-initramfs does its work as normal. Note that sid's dpkg does not yet have the triggers patch merged but there has been extensive discussion of the design and interfaces for triggers and the API should IMO be considered stable. These changes have been tested and released as part of Ubuntu 7.10 aka `gutsy gibbon'. The patch below is the consilidation of the results of our testing. So we believe that this patch can and should be safely applied to sid's initramfs-tools straight away. Ian. diff -ruN ../orig/initramfs-tools-0.85eubuntu16/debian/changelog initramfs-tools-0.85eubuntu18/debian/changelog --- ../orig/initramfs-tools-0.85eubuntu16/debian/changelog 2007-07-31 06:31:15.0 +0100 +++ initramfs-tools-0.85eubuntu18/debian/changelog 2007-08-24 15:45:43.0 +0100 @@ -1,3 +1,19 @@ +initramfs-tools (0.85eubuntu18) gutsy; urgency=low + + * Use dpkg-trigger even in our own postinst, unless we're doing +trigger processing or the running dpkg version doesn't support +reflexive triggers. This reduces update-initramfs runs from two per +upgrade batch to one per batch. + + -- Ian Jackson <[EMAIL PROTECTED]> Fri, 24 Aug 2007 15:45:38 +0100 + +initramfs-tools (0.85eubuntu17) gutsy; urgency=low + + * Use dpkg-trigger (if available and operational) to save on +calls to update-initramfs. + + -- Ian Jackson <[EMAIL PROTECTED]> Thu, 16 Aug 2007 16:03:52 +0100 + initramfs-tools (0.85eubuntu16) gutsy; urgency=low * Load thermal modules on lpia as well. This may need to change in diff -ruN ../orig/initramfs-tools-0.85eubuntu16/debian/initramfs-tools.postinst initramfs-tools-0.85eubuntu18/debian/initramfs-tools.postinst --- ../orig/initramfs-tools-0.85eubuntu16/debian/initramfs-tools.postinst 2006-12-21 23:32:07.0 + +++ initramfs-tools-0.85eubuntu18/debian/initramfs-tools.postinst 2007-08-24 15:45:02.0 +0100 @@ -25,9 +25,16 @@ -# Regenerate initramfs on upgrade -if [ "$1" = "configure" ] && [ -n "$2" ]; then +# Regenerate initramfs whenever we go to dpkg state `installed' + +if [ "x$1" != xtriggered ] && \ + dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~' +then update-initramfs -u + # ... this activates the trigger, if triggers are working +else + DPKG_MAINTSCRIPT_PACKAGE='' update-initramfs -u + # ... force it to actually happen fi #DEBHELPER# diff -ruN ../orig/initramfs-tools-0.85eubuntu16/debian/initramfs-tools.triggers initramfs-tools-0.85eubuntu18/debian/initramfs-tools.triggers --- ../orig/initramfs-tools-0.85eubuntu16/debian/initramfs-tools.triggers 1970-01-01 01:00:00.0 +0100 +++ initramfs-tools-0.85eubuntu18/debian/initramfs-tools.triggers 2007-08-16 16:03:05.0 +0100 @@ -0,0 +1 @@ +interest update-initramfs diff -ruN ../orig/initramfs-tools-0.85eubuntu16/debian/rules initramfs-tools-0.85eubuntu18/debian/rules --- ../orig/initramfs-tools-0.85eubuntu16/debian/rules 2006-12-21 23:32:07.0 + +++ initramfs-tools-0.85eubuntu18/debian/rules 2007-08-16 16:10:49.0 +0100 @@ -8,3 +8,7 @@ for x in `find scripts/ -maxdepth 1 -type d | tail -n+2`; do \ chmod -R +x $$x; \ done + +binary-install/initramfs-tools:: + install -m 644 -o 0 -g 0 debian/initramfs-tools.triggers \ + debian/initramfs-tools/DEBIAN/triggers diff -ruN ../orig/initramfs-tools-0.85eubuntu16/update-initramfs initramfs-tools-0.85eubuntu18/update-initramfs --- ../orig/initramfs-tools-0.85eubuntu16/update-initramfs 2007-04-10 16:07:41.0 +0100 +++ initramfs-tools-0.85eubuntu18/update-initramfs 2007-08-16 16:56:23.0 +0100 @@ -4,11 +4,24 @@
