Kernel-package, fix version 2 ...
Sven Luther
Apparently the initramfs-tools guys are refusing to implement the
--supported-* policy, and as such, the current packages will not allow to use
initramfs-tools, even though i designed it so that there should be no problem.
Well, after it almost came to blow and bad blood with maks about this
yesterday evening, Jonas made a proposal to change the way it works in an even
nicer way, which would allow the intiramfs-tools guys to stay in their stuborn
isolated ways, and still allow the users to use it. Thanks Jonas, you are a
great guys, and your idea is a good one, i believe.
Anyway, it goes like this :
We now allow the ramdisk to contain either of :
1) undefined
2) a single field
3) a space separated list of fields.
I will go at this in reverse. In case 3), we do as we do now, namely :
prune the scripts which are not exectuable from the list and those who do
not claim to work in the kernel version ocnfiguration we are trying to use,
and then use the first one. Notice that currently initramfs-tools will
probably return usage, and maybe fail, so it will be excluded here.
In case 2), we modify the thing a bit :
If there is only one ramdisk executable, we assume the user knows what he
does. We thus do the --supported call, and if it returns true, we fallback
to case 3), while if it is not, we issue a big fat warning and ask the user
if he really wants to use a tool which claims not to be supported and thus
potentially break the system, reply defaulting to no.
In case 1) We use some heuristic to chose the tool. This is currently a simple
conditional on the version, hard-coded in the postinst, chosing initrd-tools
or yaird (i didn't consider initramfs-tools, as it does not build yet on all
arches and was having some problems, but it may happen in the future, once the
transition is done right, and we take a decision on the tools, but seriously,
given the way the initramfs-tools guys are cooperating on this plan, i have
some doubt on the wisdom of making it the default).
In any case, i think the best idea would no more be to make a hard choice, but
maybe use some kind of heuristic, or even make it configurable at package
build time, so that it can be overiden. I need to think about this a bit more.
Coments are welcome (and anyone not caring to reply, kind of loses the right
to complain afterward, particularly if they claim i am not communicating on
this).
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Erik van Konijnenburg
Sounds workable, and it's something you can build in the kernel install script
without need for support from initrd/initramfs builders; I could live with that :-)
Perhaps we can simplify this further:
* have list of alteratives built into the kernel installer,
* allow ramdisk= in an /etc file to override this,
* run them all,
* and the first one that has exit status 0 and a non-empty image as output wins.
The nice bit about this is that it should survive with odd version
requirements like: initrd-tools works for 2.6.12, but not in combination with lvm.
The only requirement is that generators do not lie about success in their exit
status, but no flags are needed.
Regards,
Erik
Jonas Smedegaard
Hash: SHA1
On Sat, 22 Oct 2005 13:41:32 +0200
Erik van Konijnenburg <eko...@xs4all.nl> wrote:
> Perhaps we can simplify this further:
> * have list of alteratives built into the kernel installer,
> * allow ramdisk= in an /etc file to override this,
> * run them all,
> * and the first one that has exit status 0 and a non-empty image as
> output wins.
>
> The nice bit about this is that it should survive with odd version
> requirements like: initrd-tools works for 2.6.12, but not in
> combination with lvm.
>
> The only requirement is that generators do not lie about success in
> their exit status, but no flags are needed.
This works for yaird probing hardware at build time, but not tools like
mkinitramfs generating a (more or less) global ramdisk image.
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDWkUEn7DbMsAkQLgRAhHdAJ4hsDrQM45kHMHYMrMGjVaFJfReYwCeIejs
7FErNBy/J8zCW2iWqzDoNuU=
=ad3w
-----END PGP SIGNATURE-----
Sven Luther
> On Sat, Oct 22, 2005 at 08:36:50AM +0200, Sven Luther wrote:
> > In any case, i think the best idea would no more be to make a hard choice, but
> > maybe use some kind of heuristic, or even make it configurable at package
> > build time, so that it can be overiden. I need to think about this a bit more.
> >
> > Coments are welcome (and anyone not caring to reply, kind of loses the right
> > to complain afterward, particularly if they claim i am not communicating on
> > this).
>
> Sounds workable, and it's something you can build in the kernel install script
> without need for support from initrd/initramfs builders; I could live with that :-)
>
> Perhaps we can simplify this further:
> * have list of alteratives built into the kernel installer,
> * allow ramdisk= in an /etc file to override this,
> * run them all,
> * and the first one that has exit status 0 and a non-empty image as output wins.
I kind of dislike this let's try everything in turn, in particular i am afraid
of a tool which claim success and produce a broken image, and such. Also it
may considerably slow down installs.
Also the postinsts are in perl, and my perl is not all that good, so i dislike
complex modifications of this kind.
> The nice bit about this is that it should survive with odd version
> requirements like: initrd-tools works for 2.6.12, but not in combination with lvm.
Yep, but will it report failure ?
> The only requirement is that generators do not lie about success in their exit
> status, but no flags are needed.
Yeah, i still feel that the guided approach is better, but hey.
Friendly,
Sven Luther
Erik van Konijnenburg
> On Sat, Oct 22, 2005 at 01:41:32PM +0200, Erik van Konijnenburg wrote:
> > On Sat, Oct 22, 2005 at 08:36:50AM +0200, Sven Luther wrote:
> > > In any case, i think the best idea would no more be to make a hard choice, but
> > > maybe use some kind of heuristic, or even make it configurable at package
> > > build time, so that it can be overiden. I need to think about this a bit more.
> > >
> > > Coments are welcome (and anyone not caring to reply, kind of loses the right
> > > to complain afterward, particularly if they claim i am not communicating on
> > > this).
> >
> > Sounds workable, and it's something you can build in the kernel install script
> > without need for support from initrd/initramfs builders; I could live with that :-)
> >
> > Perhaps we can simplify this further:
> > * have list of alteratives built into the kernel installer,
> > * allow ramdisk= in an /etc file to override this,
> > * run them all,
> > * and the first one that has exit status 0 and a non-empty image as output wins.
>
> I kind of dislike this let's try everything in turn, in particular i am afraid
> of a tool which claim success and produce a broken image, and such. Also it
> may considerably slow down installs.
Yep, tools that produce an incorrect exit status break this approach.
The slowdown could be manageable if the most flexible tool goes in front
of the list.
> Also the postinsts are in perl, and my perl is not all that good, so i dislike
> complex modifications of this kind.
Strong argument: you're the one doing the actual coding here,
so it's important you feel happy with the approach.
> > The nice bit about this is that it should survive with odd version
> > requirements like: initrd-tools works for 2.6.12, but not in combination with lvm.
>
> Yep, but will it report failure ?
If at the end of the list all tools had non-zero exit status, you could produce a message:
"could not produce an image, and these are tools I tried ...".
> > The only requirement is that generators do not lie about success in their exit
> > status, but no flags are needed.
>
> Yeah, i still feel that the guided approach is better, but hey.
Again, you're the one building it; the guided approach works & you're comfortable
with it, so lets go that way.
Regards,
Erik
Jonas Smedegaard
Hash: SHA1
On Sat, 22 Oct 2005 08:36:50 +0200
Sven Luther <sven....@wanadoo.fr> wrote:
> We now allow the ramdisk to contain either of :
>
> 1) undefined
> 2) a single field
> 3) a space separated list of fields.
>
> I will go at this in reverse. In case 3), we do as we do now, namely :
>
> prune the scripts which are not exectuable from the list and those
> who do not claim to work in the kernel version ocnfiguration we are
> trying to use, and then use the first one. Notice that currently
> initramfs-tools will probably return usage, and maybe fail, so it
> will be excluded here.
Agree.
But this is generic, right?
The note about initramfs-tools is just informational, not some "I know
that those stubborn idiots can't provide a working ramdisk image
without accepting my patches, so they will now be left out until
cooperating - HA!" hardcoded into kernel-package or anywhere else,
right?
> In case 2), we modify the thing a bit :
>
> If there is only one ramdisk executable, we assume the user knows
> what he does. We thus do the --supported call, and if it returns
> true, we fallback to case 3), while if it is not, we issue a big fat
> warning and ask the user if he really wants to use a tool which
> claims not to be supported and thus potentially break the system,
> reply defaulting to no.
I disagree.
If there is only one ramdisk executable, then that is what the user
wants. Period.
We can add fanciness like spewing out a warning that it might not be
wise, and that warning can vary depending on what we think we know
better than the user (like "hey, stupid fuck - the days of mkinitrd is
over!" and "Wake up, dewd - you really think yaird is ever gonna handle
your EVMS-over-cryptoloop rootfs?"). But warnings only - no questions
and no defaults of ignoring the user choice.
> In case 1) We use some heuristic to chose the tool. This is currently
> a simple conditional on the version, hard-coded in the postinst,
> chosing initrd-tools or yaird (i didn't consider initramfs-tools, as
> it does not build yet on all arches and was having some problems, but
> it may happen in the future, once the transition is done right, and
> we take a decision on the tools, but seriously, given the way the
> initramfs-tools guys are cooperating on this plan, i have some doubt
> on the wisdom of making it the default).
Eh, what?
Isn't it simply the exact same thing as 3) just with a builtin default
list of tools to attempt?
> In any case, i think the best idea would no more be to make a hard
> choice, but maybe use some kind of heuristic, or even make it
> configurable at package build time, so that it can be overiden. I
> need to think about this a bit more.
This smells like a (possibly big) topic in itself. I'll comment on this
separately!
> Coments are welcome (and anyone not caring to reply, kind of loses
> the right to complain afterward, particularly if they claim i am not
> communicating on this).
I actually think you are wrong here: A bad design is bad even if noone
shouted about it at the "right" (defined by you) time.
Giving only a limited timeframe to raise concerns is not the Debian
way. But perhaps the Kernel maintainers has adopted a different group
dynamic internally?
(I sure don't like how Maximilian and Jeff handled this either, but
that's another issue!)
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDWk9ln7DbMsAkQLgRAgxBAJ0dM/akJO+ma5owm/USFIQ6cJLWtgCfRw8j
CNaVNqR+Bc9cFzVTAonH5+E=
=wX32
-----END PGP SIGNATURE-----
Jonas Smedegaard
Hash: SHA1
On Sat, 22 Oct 2005 16:55:39 +0200
Erik van Konijnenburg <eko...@xs4all.nl> wrote:
> > Also the postinsts are in perl, and my perl is not all that good,
> > so i dislike complex modifications of this kind.
>
> Strong argument: you're the one doing the actual coding here,
> so it's important you feel happy with the approach.
Well, actually, Sven is just hacking on code maintained by Manoj
Srivastava who is currently absent (and, I suppose, knows his perl
quite well).
So for short-term hacking: Yes, let's not do complex stuff.
For the longer term it is not so obvious to me that we must use a
scripting language favored by Sven.
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDWl4Fn7DbMsAkQLgRAikpAJ96Mfeo6aB5a9NVpUCkmcJP3GC1XQCghnJ+
dJLpOTbEAHwxzW81Ded90UU=
=rFHS
-----END PGP SIGNATURE-----
Sven Luther
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, 22 Oct 2005 16:55:39 +0200
> Erik van Konijnenburg <eko...@xs4all.nl> wrote:
>
> > > Also the postinsts are in perl, and my perl is not all that good,
> > > so i dislike complex modifications of this kind.
> >
> > Strong argument: you're the one doing the actual coding here,
> > so it's important you feel happy with the approach.
>
> Well, actually, Sven is just hacking on code maintained by Manoj
> Srivastava who is currently absent (and, I suppose, knows his perl
> quite well).
And more to the point, i intent to make minimal modifications, so he doesn't
feel badly that we changed all between his back when he comes back :)
Friendly,
Sven Luther
Sven Luther
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, 22 Oct 2005 08:36:50 +0200
> Sven Luther <sven....@wanadoo.fr> wrote:
>
> > We now allow the ramdisk to contain either of :
> >
> > 1) undefined
> > 2) a single field
> > 3) a space separated list of fields.
> >
> > I will go at this in reverse. In case 3), we do as we do now, namely :
> >
> > prune the scripts which are not exectuable from the list and those
> > who do not claim to work in the kernel version ocnfiguration we are
> > trying to use, and then use the first one. Notice that currently
> > initramfs-tools will probably return usage, and maybe fail, so it
> > will be excluded here.
>
> Agree.
>
> But this is generic, right?
>
> The note about initramfs-tools is just informational, not some "I know
> that those stubborn idiots can't provide a working ramdisk image
> without accepting my patches, so they will now be left out until
> cooperating - HA!" hardcoded into kernel-package or anywhere else,
> right?
Well, actually, it was just factual, so nobody is surprised as Sesse was that
initramfs-tools was not working right now.
Also, it it simportant to note that most tools should (and hopefully do),
return 1 in case of error or strange arguments being passed.
> > In case 2), we modify the thing a bit :
> >
> > If there is only one ramdisk executable, we assume the user knows
> > what he does. We thus do the --supported call, and if it returns
> > true, we fallback to case 3), while if it is not, we issue a big fat
> > warning and ask the user if he really wants to use a tool which
> > claims not to be supported and thus potentially break the system,
> > reply defaulting to no.
>
> I disagree.
>
> If there is only one ramdisk executable, then that is what the user
> wants. Period.
Well, not really, imagine the current case where he has
ramdisk=/usr/sbin/mkinitrd, for some strange reason, or more realistic,
/usr/sbin/mkinitrd.localcopy. I guess this guy don't expect things to break
when installing 2.6.14, right ?
> We can add fanciness like spewing out a warning that it might not be
> wise, and that warning can vary depending on what we think we know
> better than the user (like "hey, stupid fuck - the days of mkinitrd is
> over!" and "Wake up, dewd - you really think yaird is ever gonna handle
> your EVMS-over-cryptoloop rootfs?"). But warnings only - no questions
> and no defaults of ignoring the user choice.
So, you did not reply to me on how to handle the guys who didn't really want
to break their system. I think it is fair to stop and ask for confirmation, in
order to avoid them just seeing soem stuff scroll past the screen, maybe among
a huge install run or dist-upgrade from sarge to etch, and then make their
system unbootable.
This is like the "would you really like to format the disk" question, which
default to no in the installer, safety measures, you know.
The alternative is to provide a force_ramdisk field in kernel-img.conf, which
would be unconditionally followed, or maybe preceed the single ramdisk option
by the force keyword or follow it or something.
> > In case 1) We use some heuristic to chose the tool. This is currently
> > a simple conditional on the version, hard-coded in the postinst,
> > chosing initrd-tools or yaird (i didn't consider initramfs-tools, as
> > it does not build yet on all arches and was having some problems, but
> > it may happen in the future, once the transition is done right, and
> > we take a decision on the tools, but seriously, given the way the
> > initramfs-tools guys are cooperating on this plan, i have some doubt
> > on the wisdom of making it the default).
>
> Eh, what?
>
> Isn't it simply the exact same thing as 3) just with a builtin default
> list of tools to attempt?
Well, right now, in case 1), we provide only 1 tool, either initrd-tools for
pre-2.6.13, and yaird (or initramfs-tools) later on, something more advanced
is possible though.
> > In any case, i think the best idea would no more be to make a hard
> > choice, but maybe use some kind of heuristic, or even make it
> > configurable at package build time, so that it can be overiden. I
> > need to think about this a bit more.
>
> This smells like a (possibly big) topic in itself. I'll comment on this
> separately!
Not really, right now there are some value which are defaulting to stuff like
=K, which is sed'ed to the right values during make-kpkg's rules invocation,
the idea is to have the default set during the rules invocation, and offer a
make-kpkg option or env variable to override it, so it can be set by the user,
or the official kernel packaging.
> > Coments are welcome (and anyone not caring to reply, kind of loses
> > the right to complain afterward, particularly if they claim i am not
> > communicating on this).
>
> I actually think you are wrong here: A bad design is bad even if noone
> shouted about it at the "right" (defined by you) time.
Well, not when i personally mentioned it to them and made everyone i could see
aware of it, and asking for comments and advice, and the only reply was that i
was crazy to support yaird. And even then i am happy to hear real arguments,
like you did, which made me change my design.
> Giving only a limited timeframe to raise concerns is not the Debian
> way. But perhaps the Kernel maintainers has adopted a different group
> dynamic internally?
Well, debian's way of doing it also upto a point allow for a single maintainer
to singlehandedly hold up the work of the rest of the maintainers working on
related issues, and this is something i believe is bad for debian.
And again, saying go away you are crazy when asked for comment definitively
forfeits any rigth to critic the plan afterward without any kind of
argumentation i could recognize.
Mattia Dongili
> On Sat, Oct 22, 2005 at 04:16:00PM +0200, Sven Luther wrote:
> > Also the postinsts are in perl, and my perl is not all that good, so i dislike
> > complex modifications of this kind.
>
> Strong argument: you're the one doing the actual coding here,
> so it's important you feel happy with the approach.
I'd like to offer my help here if anything is needed, I'll dig into the
code in the next days to get a better idea of the big picture (last time
I only literaly implemented what Sven asked) ;)).
Only consider my time is somewhat limited and anyway doing big changes
while Manoj is not around might not be fair :)
--
mattia
:wq!
Sven Luther
> On Sat, Oct 22, 2005 at 04:55:39PM +0200, Erik van Konijnenburg wrote:
> > On Sat, Oct 22, 2005 at 04:16:00PM +0200, Sven Luther wrote:
> [...]
> > > Also the postinsts are in perl, and my perl is not all that good, so i dislike
> > > complex modifications of this kind.
> >
> > Strong argument: you're the one doing the actual coding here,
> > so it's important you feel happy with the approach.
>
> I'd like to offer my help here if anything is needed, I'll dig into the
> code in the next days to get a better idea of the big picture (last time
> I only literaly implemented what Sven asked) ;)).
>
> Only consider my time is somewhat limited and anyway doing big changes
> while Manoj is not around might not be fair :)
I would have said tactful, but in any case this is indeed what i want to avoid
until Manoj comes back. He said that he will be able to occasionally read and
reply to emails, so we will see.
Friendly,
Sven Luther
Jonas Smedegaard
Hash: SHA1
On Sat, 22 Oct 2005 08:36:50 +0200
Sven Luther <sven....@wanadoo.fr> wrote:
[regarding kernel-package becoming smarter at picking ramdisk-tool]
> In any case, i think the best idea would no more be to make a hard
> choice, but maybe use some kind of heuristic, or even make it
> configurable at package build time, so that it can be overiden. I
> need to think about this a bit more.
I think it is bad to put this intelligence into the package postinst
(as is currently the case as I understand it).
Instead, have the kernel packages only declare some "capabilities", and
let a separate kernel-install-helper deal with the actual install.
This ended up being a quite long email - it took me all day to write.
If response is positive it would probably make better sense to post it
on the wiki, but perhaps I am silly and you've already discussed (and
turned down) things like this long ago...
Let's for a moment assume we are dealing not only with linux-2.6,
but the following source packages:
linux-2.4
linux-2.6
hurd
kfreebsd-5
Our current ramdisk handling only relates to linux-2.6 (and linux-2.4
if anyone wanted to do maintain that) but other capabilities like
netboot support may be relevant across kernel types.
My point here is I want a tool that is generic across (Linux and
non-Linux) kernels, and usable for ramdisk generators, bootloaders and
other tools dealing with kernels. Even if right now we want to solve a
linux-specific, ramdisk-tool-specific problem.
A concrete example in the not-so-distant future (based on a true story
on #debian-kernel yesterday): Sesse wants to upgrade his machine to
2.6.15. He uses EVMS and is currently running 2.6.12.
Announcing kernel capabilities
- ------------------------------
The package linux-kernel-2.6.15-1-k7 includes the following file:
/boot/linux-2.6.15-1/kernel:
linux-initramfs
linux-sysfs
ext2fs
linux-devmapper
ext3fs
Third-party module package (and perhaps later on: module packages
generated from linux-2.6 source) can add their own files in same dir.
Perhaps later it would make sense to move module capabilities like
linux-devmapper and (for x86 but not powerpc) ext3fs out to a
separate /boot/linux-2.6.15-1/kernel-modules, so tools like braindead
bootloaders can query builtin capabilities instead of only
builtin+modular ones. But that's another story...
Installing the kernel
- ---------------------
The package linux-kernel-2.6.15-1-k7 recommends "kernel-install-helper".
In postinst the kernel package invokes "kernel-install-helper" to take
care of whatever it takes to finalize the kernel installation -
selecting a ramdisk, install/update bootloader, wrap kernel itself
(needed for some bootloaders and used to be needed for use with
etherboot).
If kernel-install-helper does not exist the postinst simply falls back
to old-style builtin script.
Selecting ramdisk tool
- ----------------------
The first implementation of kernel-install-helper does exactly the same
as proposed for kernel-package v2 (order reversed here compared to
earlier discussion):
1) If ramdisk=[colon-seperated list of tools]: try them one by one:
a) If tool does not exist, skip to next tool
b) If tool does not accept host and target kernels, skip to next tool
c) Use tool blindly. If tool fails, fail with error
d) if no tools left, fail with error
2) If ramdisk=[a single tool]: use tool. If tool fails, fail with error
3) If ramdisk=[undefined]: use builtin list and do like 1)
That's v1 of the implementation. Let's start with that!
Second implementation do similar, but instead of the current "run if
acceptable with this host and target kernel versions", it first queries
all tools for a list of supported/required capabilites of both host and
target kernels. Yaird would respond that it requires
"linux-initramfs,linux-sysfs" for both host and target kernels (which
equals kernels since 2.6.8), and that it supports
"ext2fs,ext3fs,xfs" (but not yet linux-evms). initramfs would respond
(I guess) that it requires nothing for host kernel but
"linux-initramfs,udev" for target kernel (or whatever is the reason
behind the current 2.6.12 restriction).
So adjust the logic for v1 with following change to case 1b:
b) Query tool for --{supported|required}-{host|target}-capabilities
I) If query fails: Use tool with --supported-{host|target}-version
II) If query returns negative: Skip to next tool
III) If query returns positive: Use tool
As soon as all (2!) tools that currently support host/target version
restrictions have switched to supporting the query mode, we can drop
case 1bI. But if Jeff and Maximilian for some reason choose to add
version restrictions but refuse to support capability querying then we
just leave it support for both.
We probably soon want some enhancements - like a "keep-trying" option
for case 1c, or interactive choice of ramdisk tool (like dictionaries
today) if more than one i valid. But the above should be possible
without any changes to the current documented format
of /etc/kernel-pkg.conf and - important! - without too much coding, so
let's keep it at that first.
Oh, and off course the kernel-install-helper package should take over
ownership of /etc/kernel-pkg.conf, with debconf support on the TODO
list ;-)
Using capabilities
- ------------------
So, would all these changes lead to succes for Sesse?
Well, assuming EVMS requires only the Linux devmapper and
initramdisk-tools was either explicitly chosen by Sesse or "elected" by
the kernel-helper-tool, then yes.
If both yaird and initramfs-tools installed then yaird would be favored
due to its kernel-version support, try to run, but fail. The frustrated
Sesse would then (as he actually explained on IRC that he tried)
uninstall yaird or explicitly choose to use initramfs-tools and it would
work as above.
A little down the road then...
1) kernel-install-helper would add "required-capabilities"
to /etc/kernel-pkg.conf
2) An updated evms package would suggest Sesse through debconf to add
"linux-devmapper" to the list of local required capabilities
3) kernel-install-helper would pick initramfs-tools because yaird
considered linux-devmapper an unknown (and thus unsupported) target
capability
Or...
1) A newer yaird would make use of its build-time probing in the
wrapper and include "unknown-filesystem" as an (always impossible)
requirement when it fails to parse /etc/fstab
2) kernel-install-helper would pick initramfs-tools because yaird
includes "unknown-rootfs" as target requirement
If EVMS still (as it says in the long description of the package)
requires a kernel compiled with kernel-patch-evms applied then Sesse
would need to manually add a new file /boot/linux-2.6.15-1/local
containing the single word "linux-devmapper".
A little down the road then...
1) Kernel patch packages would hint about added capabilities
1) kernel-package would recognize and include kernel patch package
capability hints
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDWqoCn7DbMsAkQLgRAmgSAKCI36WyTajWZF301xVI+ofYbMbrKwCeInp4
1FVL+gkdg21CMMP68FFalcw=
=pjO4
-----END PGP SIGNATURE-----
Sven Luther
> On Sat, Oct 22, 2005 at 04:55:39PM +0200, Erik van Konijnenburg wrote:
> > On Sat, Oct 22, 2005 at 04:16:00PM +0200, Sven Luther wrote:
> [...]
> > > Also the postinsts are in perl, and my perl is not all that good, so i dislike
> > > complex modifications of this kind.
> >
> > Strong argument: you're the one doing the actual coding here,
> > so it's important you feel happy with the approach.
>
> I'd like to offer my help here if anything is needed, I'll dig into the
> code in the next days to get a better idea of the big picture (last time
> I only literaly implemented what Sven asked) ;)).
>
> Only consider my time is somewhat limited and anyway doing big changes
> while Manoj is not around might not be fair :)
BTW, my new plan makes me consider two things :
1) how can i check if there is only one entry in the ramdisk= line ? Reading
the length of the list, or doing a shift and checking for and empty list ?
The second issue is not really related to this plan, but we really want to
debconfify the kernel-package kernel scripts, this would mean replacing all
die and printing to stdout with proper debconf messages, and inputs in the
same way, and maybe redesigning some. I can do this in shell, but never tried
the perl solution previously.
Friendly,
Sven Luther
Jonas Smedegaard
Hash: SHA1
On Sat, 22 Oct 2005 23:50:10 +0200
Sven Luther <sven....@wanadoo.fr> wrote:
> BTW, my new plan makes me consider two things :
>
> 1) how can i check if there is only one entry in the ramdisk=
> line ? Reading the length of the list, or doing a shift and checking
> for and empty list ?
split it with the delimiting character (I proposed colon - as in
$PATH - but don't know if it makes better sense to use comma or space).
Here's what you deciphered yourself tonight in yaird, splitting a path
into directoy/file components:
my @components = split (/\/+/, $path);
If you want _either_ colon, comma or whitespace as delimiter (not sure
that is a good idea though) then something like this should work:
my @entries = split (/[:,\s]+/, $line);
> The second issue is not really related to this plan, but we really
> want to debconfify the kernel-package kernel scripts, this would mean
> replacing all die and printing to stdout with proper debconf
> messages, and inputs in the same way, and maybe redesigning some. I
> can do this in shell, but never tried the perl solution previously.
Please do not bloat the postinst code! Separate it into a helper tool
instead!
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDWuCcn7DbMsAkQLgRAuySAJ9glkhVfqrv59et5495ITj97Jnn/QCdGZQX
qTpx9Tnccq8UStOUbCpx3Xk=
=B/Le
-----END PGP SIGNATURE-----
Sven Luther
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, 22 Oct 2005 23:50:10 +0200
> Sven Luther <sven....@wanadoo.fr> wrote:
>
> > BTW, my new plan makes me consider two things :
> >
> > 1) how can i check if there is only one entry in the ramdisk=
> > line ? Reading the length of the list, or doing a shift and checking
> > for and empty list ?
>
> split it with the delimiting character (I proposed colon - as in
> $PATH - but don't know if it makes better sense to use comma or space).
>
>
> Here's what you deciphered yourself tonight in yaird, splitting a path
> into directoy/file components:
>
> my @components = split (/\/+/, $path);
>
>
> If you want _either_ colon, comma or whitespace as delimiter (not sure
> that is a good idea though) then something like this should work:
>
> my @entries = split (/[:,\s]+/, $line);
Well, we already do that, in fact :
(split (/ /, $ramdisk));
But the problem is not how to split it, but how to detect it is of length 1,
that is having the legacy single entry in the field.
Not sure if allowing copa, colon or whitespace delimitation clashes with the
filenames though, as some may use comas.
> > The second issue is not really related to this plan, but we really
> > want to debconfify the kernel-package kernel scripts, this would mean
> > replacing all die and printing to stdout with proper debconf
> > messages, and inputs in the same way, and maybe redesigning some. I
> > can do this in shell, but never tried the perl solution previously.
>
> Please do not bloat the postinst code! Separate it into a helper tool
> instead!
No way, i think you are misunderstanding here. The current code does :
print STDERR <<"EOINFOMSG";
Using $ramdisk to build the ramdisk.
Other suitable ramdisk generating tools : @ramdisklist.
Full list of probed ramdisk generating tools : $ramdiskorig.
EOINFOMSG
;
And we will replace it with (shell version given) :
db_subst kernel-package/postinst_ramdisk $ramdisk
db_subst kernel-package/postinst_ramdisklist $ramdisklist
db_subst kernel-package/postinst_ramdiskorig $ramdiskorig
db_input high kernel-package/postinst_ramdisk_verbose_output || true
And then list in a template file those kernel-package/postinst_* with the
corresponding text above, and so on.
This allow to translate those templates, to select different questions at
different priorities, and do generic preseeding of those responses for
automatic installation. Not to mention its effect on usability and such.
Furthermore it has been since before sarge policy that all user questions need
to use debconf, and it was only skipped because Manoj didn't want to do those
change (probably for lack of time), and nobody jumped in. Now is the time
though.
Does that clarify it, and if not, please explain how i could put this in a
helper tool ?
Erik van Konijnenburg
> On Sun, Oct 23, 2005 at 03:00:12AM +0200, Jonas Smedegaard wrote:
> > On Sat, 22 Oct 2005 23:50:10 +0200 Sven Luther <sven....@wanadoo.fr> wrote:
> > > 1) how can i check if there is only one entry in the ramdisk=
> > > line ? Reading the length of the list, or doing a shift and checking
> > > for and empty list ?
> >
> > split it with the delimiting character (I proposed colon - as in
> > $PATH - but don't know if it makes better sense to use comma or space).
> >
> >
> > Here's what you deciphered yourself tonight in yaird, splitting a path
> > into directoy/file components:
> >
> > my @components = split (/\/+/, $path);
> >
> >
> > If you want _either_ colon, comma or whitespace as delimiter (not sure
> > that is a good idea though) then something like this should work:
> >
> > my @entries = split (/[:,\s]+/, $line);
>
> Well, we already do that, in fact :
>
> (split (/ /, $ramdisk));
>
> But the problem is not how to split it, but how to detect it is of length 1,
> that is having the legacy single entry in the field.
Two options:
a) for array @entries, $#entries will contain index of last element.
if that is -1, there were no elements, if 0, there's exactly
one, named $entries[0].
b) if @entries is used in a scalar context, it will be interpreted as
number of elements in the array:
if (@entries == 1) {print "Just one\n"; }
Regards,
Erik
Sven Luther
I implemented something using scalar(@ramdisklist). Works but maybe not as
nice.
BTW, can i do :
if ((scalar @ramdisklist) == 1) ...
?
Friendly,
Sven Luther
Mattia Dongili
[...]
>
> if ((scalar @ramdisklist) == 1) ...
>
> ?
yes
--
mattia
:wq!
Mattia Dongili
> On Sun, Oct 23, 2005 at 03:00:12AM +0200, Jonas Smedegaard wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Sat, 22 Oct 2005 23:50:10 +0200
> > Sven Luther <sven....@wanadoo.fr> wrote:
> > > The second issue is not really related to this plan, but we really
> > > want to debconfify the kernel-package kernel scripts, this would mean
> > > replacing all die and printing to stdout with proper debconf
> > > messages, and inputs in the same way, and maybe redesigning some. I
> > > can do this in shell, but never tried the perl solution previously.
> >
> > Please do not bloat the postinst code! Separate it into a helper tool
> > instead!
>
> No way, i think you are misunderstanding here. The current code does :
>
> print STDERR <<"EOINFOMSG";
> Using $ramdisk to build the ramdisk.
> Other suitable ramdisk generating tools : @ramdisklist.
> Full list of probed ramdisk generating tools : $ramdiskorig.
> EOINFOMSG
> ;
>
> And we will replace it with (shell version given) :
>
> db_subst kernel-package/postinst_ramdisk $ramdisk
> db_subst kernel-package/postinst_ramdisklist $ramdisklist
> db_subst kernel-package/postinst_ramdiskorig $ramdiskorig
> db_input high kernel-package/postinst_ramdisk_verbose_output || true
/me looking at Debconf::Client::ConfModule
the above seems as easy as doing (untested):
use Debconf::Client::ConfModule ':all';
subst('kernel-package/postinst_ramdisk', 'key_ramdisk', $ramdisk);
...
input('high', 'kernel-package/postinst_ramdisk_verbose_output');
my @ret = go();
my $answer = get('kernel-package/postinst_ramdisk_verbose_output');
if ($answer =~ /^yes$/i) {
...
}
I'll look at it further, now.
--
mattia
:wq!
Sven Luther
Indeed, the most difficult part here should be to chose the priorities to ask
questions and such.
Friendly,
Sven Luther
Jonas Smedegaard
Hash: SHA1
On Sun, 23 Oct 2005 08:08:50 +0200
Sven Luther <sven....@wanadoo.fr> wrote:
> On Sun, Oct 23, 2005 at 03:00:12AM +0200, Jonas Smedegaard wrote:
> > On Sat, 22 Oct 2005 23:50:10 +0200
> > Sven Luther <sven....@wanadoo.fr> wrote:
> Not sure if allowing copa, colon or whitespace delimitation clashes
> with the filenames though, as some may use comas.
Agreed. Stay with the space delimitor. It is backwards compatible (I
notice now), and that is important.
> > > The second issue is not really related to this plan, but we really
> > > want to debconfify the kernel-package kernel scripts, this would
> > > mean replacing all die and printing to stdout with proper debconf
> > > messages, and inputs in the same way, and maybe redesigning some.
> > > I can do this in shell, but never tried the perl solution
> > > previously.
> >
> > Please do not bloat the postinst code! Separate it into a helper
> > tool instead!
>
> No way, i think you are misunderstanding here. The current code does :
>
> print STDERR <<"EOINFOMSG";
> Using $ramdisk to build the ramdisk.
> Other suitable ramdisk generating tools : @ramdisklist.
> Full list of probed ramdisk generating tools : $ramdiskorig.
> EOINFOMSG
> ;
>
> And we will replace it with (shell version given) :
[snip - nice and dandy, but irrelevant for ramdisk enhancement!]
You will not introduce debconf, please. You will stick to same coding
style as Manoj uses.
Manoj does not use debconf, so you will not either. Not without consent
from Manoj. That would be outright stupid. Approaches like that helps
explain the tension between you and the initramfs-tools maintainers!
> Furthermore it has been since before sarge policy that all user
> questions need to use debconf, and it was only skipped because Manoj
> didn't want to do those change (probably for lack of time), and
> nobody jumped in. Now is the time though.
Then deal with that separately: File an RC bug about k-p breaking
policy regarding debconf, and do an NMU fixing that issue.
Such issue is separate from the issue of handling new ramdisk querying
interface, so please treat it as such.
I do not want the ramdisk enhancements dropped again by Manoj when he
gets back because you got carried away and "fixed" other frustrating
annoyances concurrently!
> Does that clarify it, and if not, please explain how i could put this
> in a helper tool ?
this should clarify my stand:
Now: Add support for querying interface of ramdisk tools
Later (option1): Persuade Manoj to use debconf in k-p
Later (option2): Persuade Manoj to use new kernel-install-helper
Later (option3): Leave as is
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDW4n7n7DbMsAkQLgRAlXQAJ9SDyLjGeBMWPdcNL3DvU9JHRcsvACcCSLt
cIOsYZEQ5Z8vuYLX1ZkfNdw=
=8NbS
-----END PGP SIGNATURE-----
Sven Luther
> On Sat, Oct 22, 2005 at 04:55:39PM +0200, Erik van Konijnenburg wrote:
> > On Sat, Oct 22, 2005 at 04:16:00PM +0200, Sven Luther wrote:
> [...]
> > > Also the postinsts are in perl, and my perl is not all that good, so i dislike
> > > complex modifications of this kind.
> >
> > Strong argument: you're the one doing the actual coding here,
> > so it's important you feel happy with the approach.
>
> I'd like to offer my help here if anything is needed, I'll dig into the
> code in the next days to get a better idea of the big picture (last time
> I only literaly implemented what Sven asked) ;)).
Mattia, could you look over this code :
chomp (my $hostversion = `uname -r`);
my @ramdisklist =
grep {
my $ret = system ("$_ --supported-host-version=$hostversion --supported-target-version=$version 1>/dev/null 2>&1");
-x and (
$ret == 0 or (
$ret == 1 and (
(($ramdisk eq "/usr/sbin/mkinitrd") and
(system ("dpkg", "--compare-versions", "$version", "lt", "2.6.13") == 0)) or
(($ramdisk eq "/usr/sbin/mkinitramfs") and
(system ("dpkg", "--compare-versions", "$version", "lt", "2.6.12") == 1)) or
(($ramdisk eq "/usr/sbin/mkinitrd.yaird") and
(system ("dpkg", "--compare-versions", "$version", "lt", "2.6.8") == 1) and
(system ("dpkg", "--compare-versions", "$hostversion", "lt", "2.6.8") == 1))
)
)
)
}
(split (/ /, $ramdisk));
my $ramdiskorig = $ramdisk;
defined ($ramdisk = shift @ramdisklist)
or die ("Failed to find suitable ramdisk generation tool for kernel version $version on running kernel $hostversion in $ramdiskorig\n");
print STDERR "Using $ramdisk to build the ramdisk.";;
if (@ramdisklist) { print STDERR "Other suitable ramdisk generating tools : @ramdisklist.\n"; }
print STDERR "Full list of probed ramdisk generating tools : $ramdiskorig.\n";
and tell me if there is any glaring error in it.
The code does the following :
1) tests if the tool exists.
2) tests if the tool returns 0 for the given host and target version.
3) if the tool returns 1, this means --supported-* is not supported, do an explicit check.
Checks are :
3.1) mkinitrd is ok if target < 2.6.13.
3.2) mkinitramfs is ok if target >= 2.6.12.
3.3) mkinitrd.yaird is ok if target >= 2.6.8 and host >= 2.6.8.
Friendly,
Sven Luther
Mattia Dongili
On Mon, October 24, 2005 9:58 am, Sven Luther said:
[...]
> Mattia, could you look over this code :
>
> chomp (my $hostversion = `uname -r`);
> my @ramdisklist =
> grep {
> my $ret = system ("$_ --supported-host-version=$hostversion
> --supported-target-version=$version 1>/dev/null 2>&1");
> -x and (
> $ret == 0 or (
> $ret == 1 and (
> (($ramdisk eq "/usr/sbin/mkinitrd") and
> (system ("dpkg", "--compare-versions", "$version", "lt",
> "2.6.13") == 0)) or
> (($ramdisk eq "/usr/sbin/mkinitramfs") and
> (system ("dpkg", "--compare-versions", "$version", "lt",
> "2.6.12") == 1)) or
> (($ramdisk eq "/usr/sbin/mkinitrd.yaird") and
> (system ("dpkg", "--compare-versions", "$version", "lt",
> "2.6.8") == 1) and
> (system ("dpkg", "--compare-versions", "$hostversion", "lt",
> "2.6.8") == 1))
> )
> )
> )
> }
> (split (/ /, $ramdisk));
you could rewrite the grep this way:
my @ramdisklist =
grep {
-x and (
system ("$_ --supported-host-version=$hostversion
--supported-target-version=$version 1>/dev/null 2>&1") == 0
or (
(($ramdisk eq "/usr/sbin/mkinitrd") and (system ("dpkg",
"--compare-versions", "$version", "lt", "2.6.13") == 0))
or
(($ramdisk eq "/usr/sbin/mkinitramfs") and (system ("dpkg",
"--compare-versions", "$version", "lt", "2.6.12") == 1))
or
(($ramdisk eq "/usr/sbin/mkinitrd.yaird") and (system
("dpkg", "--compare-versions", "$version", "lt", "2.6.8") ==
1) and (system ("dpkg", "--compare-versions",
"$hostversion", "lt", "2.6.8") == 1))
)
)
}
(split (/ /, $ramdisk));
this way you _first_ test for '-x', only then you go ahead with the rest
of the stuff.
> my $ramdiskorig = $ramdisk;
> defined ($ramdisk = shift @ramdisklist)
> or die ("Failed to find suitable ramdisk generation tool for kernel
> version $version on running kernel $hostversion in $ramdiskorig\n");
>
> print STDERR "Using $ramdisk to build the ramdisk.";;
> if (@ramdisklist) { print STDERR "Other suitable ramdisk generating
> tools : @ramdisklist.\n"; }
> print STDERR "Full list of probed ramdisk generating tools :
> $ramdiskorig.\n";
>
> and tell me if there is any glaring error in it.
>
> The code does the following :
>
> 1) tests if the tool exists.
> 2) tests if the tool returns 0 for the given host and target version.
> 3) if the tool returns 1, this means --supported-* is not supported, do an
> explicit check.
> Checks are :
>
> 3.1) mkinitrd is ok if target < 2.6.13.
> 3.2) mkinitramfs is ok if target >= 2.6.12.
> 3.3) mkinitrd.yaird is ok if target >= 2.6.8 and host >= 2.6.8.
other than the grep issue, seems ok to me
--
mattia
:wq!
Sven Luther
Oh, right, altough your code disregard the fact that i need to check for two
return values of the --supported* case.
Can i do :
-x and ( my $ret = ...; $ret == 0 or ($ret == 1 and ... ))
or maybe ?
-x and { my $ret = ...; $ret == 0 or ($ret == 1 and ... )}
Friendly,
Sven Luther
Jonas Smedegaard
Hash: SHA1
On Mon, 24 Oct 2005 10:58:06 +0200
Sven Luther <sven....@wanadoo.fr> wrote:
> Oh, right, altough your code disregard the fact that i need to check
> for two return values of the --supported* case.
It also seems, Sven, that you do not follow the the logic laid out here
(which we agreed on, except for the use of debconf[1]):
http://minbar.dodds.net/~vorlon/k-p-pseudocode
If I understand that correctly, then why don't you?
And it was pointed out earlier to separate arguments in system() calls.
I offer to take a look at all of this, and also look at the perl coding
style already used by Manoj and mimic that as I best can. Would you
like that, or would you rather do this yourself?
If you agree, I will post so SVN but not upload a new NMU without
your acknowledgement, Sven.
- Jonas
[1] I do not claim that we agreed _not_ to use debconf, just that we
didn't agree on using it ;-)
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDXKiKn7DbMsAkQLgRAifsAJ0fie7lGhadZ8YskXysk5g1Og8ewQCbBWSO
fzngJpj+dSW+1HlACrPhitk=
=deZW
-----END PGP SIGNATURE-----
Sven Luther
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, 24 Oct 2005 10:58:06 +0200
> Sven Luther <sven....@wanadoo.fr> wrote:
>
> > Oh, right, altough your code disregard the fact that i need to check
> > for two return values of the --supported* case.
>
> It also seems, Sven, that you do not follow the the logic laid out here
> (which we agreed on, except for the use of debconf[1]):
> http://minbar.dodds.net/~vorlon/k-p-pseudocode
>
> If I understand that correctly, then why don't you?
I don't get this, my yesterday upload indeed didn't follow this, but todays do
it ok, with the exception that we don't wait and ask in case of failure. The
procedure is :
1) if --supported is supported and returns 0, we keep the tool.
2) if --supported is supported and returns 2, we drop the tool.
3) if --supported is not supported, then we do explicit checks builtin into
k-p for the thre major tools, and drop it if it fails.
This is basically my understanding of Steve's pseudo-code, and Steve also
seemed to not contradict this this morning, i think.
> And it was pointed out earlier to separate arguments in system() calls.
Yep. But i did, did i not ? The code is :
my @ramdisklist =
grep {
my $ret = system ("$_ --supported-host-version=$hostversion --supported-target-version=$version 1>/dev/null 2>&1");
-x and (
$ret == 0 or (
$ret == 1 and (
(($ramdisk eq "/usr/sbin/mkinitrd") and
(system ("dpkg", "--compare-versions", "$version", "lt", "2.6.13") == 0)) or
(($ramdisk eq "/usr/sbin/mkinitramfs") and
(system ("dpkg", "--compare-versions", "$version", "lt", "2.6.12") == 1)) or
(($ramdisk eq "/usr/sbin/mkinitrd.yaird") and
(system ("dpkg", "--compare-versions", "$version", "lt", "2.6.8") == 1) and
(system ("dpkg", "--compare-versions", "$hostversion", "lt", "2.6.8") == 1))
)
)
)
}
(split (/ /, $ramdisk));
As i understand, you can do the separating argument trick if you don't
redirect as the first call does, i am no perl expert though, but that is what
i was told (by you maybe ? don't remember).
> I offer to take a look at all of this, and also look at the perl coding
> style already used by Manoj and mimic that as I best can. Would you
> like that, or would you rather do this yourself?
Cool with me, i would rather someone else had a second look.
> If you agree, I will post so SVN but not upload a new NMU without
> your acknowledgement, Sven.
Ok, i uploaded .3 with the above code, since we need to upload -rc5, but this
can still be changed.
Don't forget to mirror the change in the preinst script too.
> [1] I do not claim that we agreed _not_ to use debconf, just that we
> didn't agree on using it ;-)
Well, Steve made some comment about it being time for k-p to be debconfified,
i still don't get what you have against debconfification, but i agree that it
should be done separatedly from the other fixes.
Mattia Dongili
On Mon, October 24, 2005 10:58 am, Sven Luther said:
> On Mon, Oct 24, 2005 at 11:01:53AM +0200, Mattia Dongili wrote:
[...]
>> you could rewrite the grep this way:
>>
>> my @ramdisklist =
>> grep {
>> -x and (
>> system ("$_ --supported-host-version=$hostversion
>> --supported-target-version=$version 1>/dev/null 2>&1") == 0
>> or (
>> (($ramdisk eq "/usr/sbin/mkinitrd") and (system ("dpkg",
>> "--compare-versions", "$version", "lt", "2.6.13") == 0))
>> or
>> (($ramdisk eq "/usr/sbin/mkinitramfs") and (system
>> ("dpkg",
>> "--compare-versions", "$version", "lt", "2.6.12") == 1))
>> or
>> (($ramdisk eq "/usr/sbin/mkinitrd.yaird") and (system
>> ("dpkg", "--compare-versions", "$version", "lt", "2.6.8") ==
>> 1) and (system ("dpkg", "--compare-versions",
>> "$hostversion", "lt", "2.6.8") == 1))
>> )
>> )
>> }
>> (split (/ /, $ramdisk));
>
> Oh, right, altough your code disregard the fact that i need to check for
> two return values of the --supported* case.
oh, I'm just not considering the fact that '$_ --supported-*' can return
other values than just 0 or 1. Is this the case? AFAIR you were talking of
some tool returning 2 in some case, if so please discard my suggestion?
I was just assuming that $ret==0 is ok and any other value is not thus
trying to reduce the case "A or (!A and (...))" :)
> Can i do :
>
> -x and ( my $ret = ...; $ret == 0 or ($ret == 1 and ... ))
>
> or maybe ?
>
> -x and { my $ret = ...; $ret == 0 or ($ret == 1 and ... )}
well, consider that the curly brackets of grep are creating an anonymous
function so you could do all the worst things there :)
Not tested, I'm at work now, but just to give you an idea:
grep
{
my $ret = 0;
if (-x) {
my $supp_host_target = system("$_ --supported... 1>/dev/null 2>&1");
$ret = ($supp_host_target == 0 or ($supp_host_target == 1 and (...)));
}
}
@array;
--
mattia
:wq!
Sven Luther
hehe, indeed and system returns values shifted by 8 even. Current code is :
my @ramdisklist =
grep {
if (-x) {
my $ret = system ("$_ --supported-host-version=$hostversion --supported-target-version=$version 1>/dev/null 2>&1") >> 8;
$ret == 0 or (
$ret == 1 and (
(("$_" eq "/usr/sbin/mkinitrd") and
(system ("dpkg", "--compare-versions", "$version", "lt", "2.6.13") == 0)) or
(("$_" eq "/usr/sbin/mkinitramfs") and
(system ("dpkg", "--compare-versions", "$version", "lt", "2.6.12") == 1)) or
(("$_" eq "/usr/sbin/mkinitrd.yaird") and
(system ("dpkg", "--compare-versions", "$version", "lt", "2.6.8") == 1) and
(system ("dpkg", "--compare-versions", "$hostversion", "lt", "2.6.8") == 1))
)
)
}
}
(split (/ /, $ramdisk));
As you suggested below, does this sound reasonable ? Seems to work fine.
Friendly,
Sven Luther
Mattia Dongili
> On Mon, Oct 24, 2005 at 12:53:22PM +0200, Mattia Dongili wrote:
>> [sorry again for line wrapping]
> As you suggested below, does this sound reasonable ? Seems to work fine.
Yes, looks better now ;)
--
mattia
:wq!
Sven Luther
> On Mon, October 24, 2005 1:28 pm, Sven Luther said:
> > On Mon, Oct 24, 2005 at 12:53:22PM +0200, Mattia Dongili wrote:
> >> [sorry again for line wrapping]
> [...]
> > As you suggested below, does this sound reasonable ? Seems to work fine.
>
> Yes, looks better now ;)
Well, i did go for this syntax :
$ret == 1 and (
$_ eq "/usr/sbin/mkinitrd" ?
compare_versions($version, "2.6.13") == 0
:
$_ eq "/usr/sbin/mkinitramfs") ?
compare_versions($version, "2.6.12") == 1
:
$_ eq "/usr/sbin/mkinitrd.yaird" ?
compare_versions($version, "2.6.8") == 1 &&
compare_versions($hostversion, "2.6.8") == 1
:
0
)
Friendly,
Sven Luther