If I install by copying /boot/fs/qnxbase.qfs from the 6.2.1 CD
to an initialised disk partition and use /boot/fs/qnxbase.ifs
from the CD as the boot image, I get a system which purports to
be 6.2.1. However, uname reports only the kernel version, not
that of the packages in qnxbase.qfs. The packages are still those
from 6.2.0.
The normal installation will replace and deactivate the packages
in qnxbase.qfs with updated ones from the CD rep621 repository
when it installs/updates Momentics.
We don’t want to install Momentics, as we do not have disk space.
We would like the installer to update only those packages in
qnxbase.qfs that are out of date. This can be done manually, by
copying the relevant packages off the CD and installing them
separately, but that is error prone and not a general solution.
Is there a way to get one of the qnx installers to do this?
Alternatively, is there a way on a fully installed 6.2.1 system to
regenerate the qnxbase.qfs (not the ifs) to be up to date?
Thanks for any help
William Morris
Alternatively, is there a way on a fully installed 6.2.1 system to
regenerate the qnxbase.qfs (not the ifs) to be up to date?
Not really. The qnxbase.qfs is the “base” set of packages. They are
replaced as required from newer packages you install. What is your end goal?
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris McKillop wrote:
Alternatively, is there a way on a fully installed 6.2.1 system to
regenerate the qnxbase.qfs (not the ifs) to be up to date?
Not really. The qnxbase.qfs is the “base” set of packages. They are
replaced as required from newer packages you install. What is your end goal?
To get a 6.2.1 base system (qnxbase.qfs + updates) without having
to install the whole of Momentics (which will not fit on our flash
disk).
William
The QNX installers do not yet support this feature, William. It’s on our
“would-be-nice” list, though.
“William Morris” <william@bangel.demon.co.uk> wrote in message
news:3EAE31F4.AEB8BDFB@bangel.demon.co.uk…
Chris McKillop wrote:
Alternatively, is there a way on a fully installed 6.2.1 system to
regenerate the qnxbase.qfs (not the ifs) to be up to date?
Not really. The qnxbase.qfs is the “base” set of packages. They are
replaced as required from newer packages you install. What is your end
goal?
To get a 6.2.1 base system (qnxbase.qfs + updates) without having
to install the whole of Momentics (which will not fit on our flash
disk).
William
Jerry Chappell wrote:
The QNX installers do not yet support this feature, William. It’s on our
“would-be-nice” list, though.
Thanks Jerry.
Just today we have had to revert to 6.2.0 because of
problems with Apache/PHP on 6.2.1, so the problem of
installing 6.2.1 cleanly and repeatably has just gone
to the end of my “would-be-nice” list 
In case I need to look at this again, are there any
QNX functions/libraries for manipulating, packages
files and revisions (and for maybe talking to fs-pkg)?
Thanks again
William
Just today we have had to revert to 6.2.0 because of
problems with Apache/PHP on 6.2.1, so the problem of
installing 6.2.1 cleanly and repeatably has just gone
to the end of my “would-be-nice” list >
Yes, a known issue. You can use the external php binary as a cgi handler
on 6.2.1 as a work-around until the trouble is resolved.
In case I need to look at this again, are there any
QNX functions/libraries for manipulating, packages
files and revisions (and for maybe talking to fs-pkg)?
When building for a target system I normally write a set of scripts to
build an image based on the current install. This is how I have personally
be doing it since the QNX4 days. It de-couples you from the install method
used on your development machines and allows for easy, automated building
of your target system.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris McKillop wrote:
When building for a target system I normally write a set of scripts to
build an image based on the current install. This is how I have personally
be doing it since the QNX4 days. It de-couples you from the install method
used on your development machines and allows for easy, automated building
of your target system.
I think you are referring to targets which contain their executables in
a boot image and real files, not to the use of the package filesystem.
Do you recommend against using fs-pkg in a target system and if so
please explain why? I can see that there are performance issues, but
where those are not pertinent, what reasons might I have to take this
path?
What I was hoping for was access to libraries of functions used within
the installers for determining the active packages and their versions,
for parsing new packages and for comparing them against the active list
to determine which packages need to be updated. I imagined as an
alternative that some of this might be achieved by sending messages to
fs-pkg.
I can parse /etc/system/package/packages and individual package files
(or file names) myself, but that is repeating (probably not as well)
what QNX must anyway do itself.
Thanks for replying
William
I think you are referring to targets which contain their executables in
a boot image and real files, not to the use of the package filesystem.
Do you recommend against using fs-pkg in a target system and if so
please explain why? I can see that there are performance issues, but
where those are not pertinent, what reasons might I have to take this
path?
Just depends on what you want to accomplish. Right now you aren’t going to
be able to easily do what you want to do (update qnxbase.qfs). In fact,
I am not really sure the consequences of trying to update it.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris McKillop wrote:
Just depends on what you want to accomplish. Right now you aren’t going to
be able to easily do what you want to do (update qnxbase.qfs).
In fact,
I am not really sure the consequences of trying to update it.
Sure you do if you are using 6.2.1. Your system works doesn’t it
The QNX installer ‘updates’ qnxbase.qfs by installing all the new
packages from the CD and deactivating the relevant old ones in
qnxbase.qfs when it installs/updates Momentics. Of course it doesn’t
actually touch the qnxbase.qfs file, it is fs-pkg that does the real
work or activating and deactivating at runtime. That is why I figure
fs-pkg could tell me what I want to know.
This is just my estimation of what occurs derived through observation
and thought. Please correct me if I have the wrong idea of how the
package filesystem works.
William
This is just my estimation of what occurs derived through observation
and thought. Please correct me if I have the wrong idea of how the
package filesystem works.
That is correct. What I mean is, it is possible for packages to be
patches (but I am not sure if we are using them). At which point you need
both the base and the patch package. It might just be space on the CD, but
I have always assumed there was a semi-technical reason for why we don’t
update qnxbase.qfs and instead rely on packages (6.2.0->6.2.1).
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/