As a preface to all of these, I am using the -u -b+ options to the
packager, so that I have only interactively run packager once. Now I
am re-generating the package based on the most recent previous .qpm
whose ancestry can be traced to the interactive session, but the most
recent .qpm is not necessarily directly from an interactive session.
My questions are predicated on the idea that the packager should be
useful for generating packages through a Makefile, without human
intervention. I would be more than a little surprised if QSSL is
using the packager in any other way than with the -u option, so you
must have thought of some of these things.
Previously, Jerry Chappell wrote in qdn.public.qnxrtp.devtools:
(1) Are you using a ‘basedir’ directory which holds all of your files?
If so, then when it asks for your license file, enter the location of
it on your local filesystem, with an explicit path (ie: /home/licenses/
license.txt). Packager will copy the file into a package.repdata/
directory and change the manifest entry. It should be able to
reuse this same location for the next time. Let me know if it
doesn’t.
It doesn’t. I am using a relative directory, as in
…/setup/LICENSE.TXT, which works fine on the first iteration, but on
subsequent non-interactive packager invocations, the “rep:…” is
carried from one .qpm to the next. The path I typed to the
interactive session is long gone, replaced by the “rep:…” location.
(2) Currently there’s only one destination for all generated files.
You could write a script to move the QPR when it’s finished.
If I knew what it was called, which I don’t (random insertion of -dev-
in the file name, auto-increment of build number, addition of the word
bld in all qpr’s after the first). Maybe I’ll just move all .qpr’s.
That seems sensible if somewhat heavy-handed.
(3) Package installer can be called with a -u option:
pkg-installer -u package.qpr
Not via a web repository.
The only problem is that it doesn’t yet let you confirm installation
of files before it actually does the installation.
Why can’t you use the -k option?
Because then the packager does not build the package.repdata directory
into a .qpk, so my license never gets included into the package. Only
the .qpr carries my license.
So, only .qpr carries the license, but .qpr is not usable in a
web-based repository. This seems inconsistent to me, which is why I
feel like I’m missing something.
(4) If you are using the -m option to use a previous package
as the source of your default values, make sure the package you
pass to packager is the core package, not a development package.
I suspect that you passed a Bla-dev.qpr package, so it took the
name of that package (Bla-dev), and appended -dev onto the end.
My development package has no core. It is a separate package that
only contains headers and libraries. I have Never Ever EVER typed the
extension -dev to anything ever anywhere under any circumstances to
any package ever. Never. Ever. !! 
Whew. Having said that, the packager magically adds the -dev- to my
package name, and I have no choice but to use the .qpm that it creates
in subsequent invocations, as it is the only place that carries the
updated build number. So packager adds -dev- and then adds another
one the next time.
What made packager add -dev- the first time, and how do I stop it?
(5) Note that the current version of the package installer does not
detect changes in the build number. Increment the release number
to permit updating of your software. Your version number need not
change as long as the release is incremented.
Are you talking about the PackageReleaseNumber or ReleaseVersion?
ReleaseVersion is my software version, and should not change.
Assuming you mean PackageReleaseNumber, does pkg-installer look at it?
It’s not displayed in the information window. Where is the argument
to packager that auto-increments the release?
(6) In what format are you hoping to see the manifest? I presume
that the tag names will be completely different between a QNX
package and whatever utility you’re using, so I don’t see the
advantage of writing a manifest in text format.
I’m using pax.
I like the idea of a file, one name per line, plain ASCII, without a
leading ‘/’, with shell-style globbing. If you don’t like globbing,
that can be done by a pre-processing step. It is easy to generate
lists of files using shell scripts, but it is not so easy to generate
hierarchies of XML tagged files and insert them into the correct
location in the .qpm file, being careful to remove the existing
content, especially since the Union links are actually placed within
the file list in the .qpm, rather than before or after.
(7) The package is probably not there at all. Why don’t you forward
me the package so that I can analyze it and tell you what the
problem is (> jchappell@qnx.com> ).
It is there. The package manager even believes that it is installed,
once installed with -u. It just cannot be seen in the installed
software, nor on a web repository. The files themselves are in
/pkgs/repository/Cogent/…
I’ll send it along by email.
(7a) I’m not the person to ask about deleting it, I’m afraid.
I did the old “rm -rf /pkgs/repository/Cogent/” and nothing
crashed.
Thanks,
Andrew