Packages and PE

QNX Newsgroups (Archives) qnx.cafe
1

Hi,
I’d like to have the feeling from the community about the 6.3 version,
because according to my tries from the month of June up today with Eclipse
and other changes came with this version, I’m still wondering if I stay to
6.2 or if I switch to 6.3.

For me:

The only reason to switch to 6.3 is the improvements done about Photon
developments.

The main problems are:

  1. The difference between the project management between the recursive
    makefiles and Eclipse.
    The unability to create nested projects within Eclipse is not only a
    problem of clearness in a project’s architecture but a real difficulty to
    maintain the dozens of projects based on the recursive makefiles method.
    Ok we can declare a traditional ‘C’ project an decide to not being able to
    use all wizard’s options setting.
    Convert the project? because of the PE price, we are maybe not ready to
    give a PE to each developper!

  2. The packages; this is certainly the most obvious contradiction in this
    6.3.
    New qnxinstall with features claim this their disappearence in 6.1 and we
    are still waiting for the dependency list we had before!!!
    New cl-installer features we claimed (me between others) in 6.2.
    New feature to use the packages without the package filesystem.

but in fact, QSSL decided to no more use the packages.

Anyone complained about fs-pkg problems or instability ?

I use fs-pkg on a server for 5 years 6.0 6.1 6.2 and on several targets
were I install/deinstall/copy/remove/create WITHOUT ANY PROBLEM!!!

And now?
when I develop executables, libraries, headers, etc…
How do I install it on other QNX hosts?
How do I install it on XP hosts?
Shell scripts? the same between QNX and Windows?
tar, zip? the same between QNX and Windows?
How can I know which version of any module a user use to build its program?
How can I install the modules, configuration files, etc… on a customer
target?
How can I know which version this customer uses?
How can I know that a file has been modified from the base installation?

Ok, today qnxinstall seems to not taking care of QNX_TARGET/QNX_HOST but
from my point of view, packages are the only answer to these questions!!!

I think I know the answer from Armin :wink: but I’m absolutely not ready to
use rpm. QNX packages exists, qnxinstall exists (QNX and Windows at
least), cl-installer exists, fs-pkg exists and they just have to be
updated to work with the 6.3.

Finally I want to complain about the QSSL policy which decides to remove
features without taking care about their customers point of view. And I
don’t want to discuss about core, tools or I don’t know what else. For me,
packages is a feature, a REALLY necessary feature, available from the
beginning of QNX 6, and even if QSSL decided to no more use it for its
core components (which is, from my point of view not a good idea) I can’t
understand they could decide that everybody has to forget it!!

I waiting for your opinions.

Alain.

2

Package filesystem was not very well thought-out and created lot of
consistency problems, as well as noticeable overhead. But removing it
abruptly is not a solution, of course. But then again QNX has long track
record of forcing their own interpretation of what’s best for customers onto
their customers. Nothing to be surprized about.

“Alain Bonnefoy” <alain.bonnefoy@rieter.com> wrote in message
news:ct5hjc$1e0$1@inn.qnx.com…

Hi,
I’d like to have the feeling from the community about the 6.3 version,
because according to my tries from the month of June up today with Eclipse
and other changes came with this version, I’m still wondering if I stay to
6.2 or if I switch to 6.3.

For me:

The only reason to switch to 6.3 is the improvements done about Photon
developments.

The main problems are:

  1. The difference between the project management between the recursive
    makefiles and Eclipse.
    The unability to create nested projects within Eclipse is not only a
    problem of clearness in a project’s architecture but a real difficulty to
    maintain the dozens of projects based on the recursive makefiles method.
    Ok we can declare a traditional ‘C’ project an decide to not being able to
    use all wizard’s options setting.
    Convert the project? because of the PE price, we are maybe not ready to
    give a PE to each developper!

  2. The packages; this is certainly the most obvious contradiction in this
    6.3.
    New qnxinstall with features claim this their disappearence in 6.1 and we
    are still waiting for the dependency list we had before!!!
    New cl-installer features we claimed (me between others) in 6.2.
    New feature to use the packages without the package filesystem.

but in fact, QSSL decided to no more use the packages.

Anyone complained about fs-pkg problems or instability ?

I use fs-pkg on a server for 5 years 6.0 6.1 6.2 and on several targets
were I install/deinstall/copy/remove/create WITHOUT ANY PROBLEM!!!

And now?
when I develop executables, libraries, headers, etc…
How do I install it on other QNX hosts?
How do I install it on XP hosts?
Shell scripts? the same between QNX and Windows?
tar, zip? the same between QNX and Windows?
How can I know which version of any module a user use to build its
program?
How can I install the modules, configuration files, etc… on a customer
target?
How can I know which version this customer uses?
How can I know that a file has been modified from the base installation?

Ok, today qnxinstall seems to not taking care of QNX_TARGET/QNX_HOST but
from my point of view, packages are the only answer to these questions!!!

I think I know the answer from Armin > :wink: > but I’m absolutely not ready to
use rpm. QNX packages exists, qnxinstall exists (QNX and Windows at
least), cl-installer exists, fs-pkg exists and they just have to be
updated to work with the 6.3.

Finally I want to complain about the QSSL policy which decides to remove
features without taking care about their customers point of view. And I
don’t want to discuss about core, tools or I don’t know what else. For me,
packages is a feature, a REALLY necessary feature, available from the
beginning of QNX 6, and even if QSSL decided to no more use it for its
core components (which is, from my point of view not a good idea) I can’t
understand they could decide that everybody has to forget it!!

I waiting for your opinions.

Alain.

3

Hi Igor,

I’m very happy to hear you. I wasn’t so present on the newsgroups these
last months.
In fact, I complain also about the multiplication of channels because in
fact, none of them are really active now. Too many discussion places kill
the discussions :neutral_face:.
I regret the discussions we had one or two years ago.

Well, could you tell me few words about how you manage your software
versions, installations on targets or development hosts, etc… if you are
concerned by this problem?

Thanks a lot,
Alain.
*
Igor Kovalenko wrote:

Package filesystem was not very well thought-out and created lot of
consistency problems, as well as noticeable overhead. But removing it
abruptly is not a solution, of course. But then again QNX has long track
record of forcing their own interpretation of what’s best for customers onto
their customers. Nothing to be surprized about.

“Alain Bonnefoy” <> alain.bonnefoy@rieter.com> > wrote in message
news:ct5hjc$1e0$> 1@inn.qnx.com> …

Hi,
I’d like to have the feeling from the community about the 6.3 version,
because according to my tries from the month of June up today with Eclipse
and other changes came with this version, I’m still wondering if I stay to
6.2 or if I switch to 6.3.

For me:

The only reason to switch to 6.3 is the improvements done about Photon
developments.

The main problems are:

  1. The difference between the project management between the recursive
    makefiles and Eclipse.
    The unability to create nested projects within Eclipse is not only a
    problem of clearness in a project’s architecture but a real difficulty to
    maintain the dozens of projects based on the recursive makefiles method.
    Ok we can declare a traditional ‘C’ project an decide to not being able to
    use all wizard’s options setting.
    Convert the project? because of the PE price, we are maybe not ready to
    give a PE to each developper!

  2. The packages; this is certainly the most obvious contradiction in this
    6.3.
    New qnxinstall with features claim this their disappearence in 6.1 and we
    are still waiting for the dependency list we had before!!!
    New cl-installer features we claimed (me between others) in 6.2.
    New feature to use the packages without the package filesystem.

but in fact, QSSL decided to no more use the packages.

Anyone complained about fs-pkg problems or instability ?

I use fs-pkg on a server for 5 years 6.0 6.1 6.2 and on several targets
were I install/deinstall/copy/remove/create WITHOUT ANY PROBLEM!!!

And now?
when I develop executables, libraries, headers, etc…
How do I install it on other QNX hosts?
How do I install it on XP hosts?
Shell scripts? the same between QNX and Windows?
tar, zip? the same between QNX and Windows?
How can I know which version of any module a user use to build its
program?
How can I install the modules, configuration files, etc… on a customer
target?
How can I know which version this customer uses?
How can I know that a file has been modified from the base installation?

Ok, today qnxinstall seems to not taking care of QNX_TARGET/QNX_HOST but
from my point of view, packages are the only answer to these questions!!!

I think I know the answer from Armin > :wink: > but I’m absolutely not ready to
use rpm. QNX packages exists, qnxinstall exists (QNX and Windows at
least), cl-installer exists, fs-pkg exists and they just have to be
updated to work with the 6.3.

Finally I want to complain about the QSSL policy which decides to remove
features without taking care about their customers point of view. And I
don’t want to discuss about core, tools or I don’t know what else. For me,
packages is a feature, a REALLY necessary feature, available from the
beginning of QNX 6, and even if QSSL decided to no more use it for its
core components (which is, from my point of view not a good idea) I can’t
understand they could decide that everybody has to forget it!!

I waiting for your opinions.

Alain.

4

Igor Kovalenko wrote:

Package filesystem was not very well thought-out and created lot of
consistency problems, as well as noticeable overhead. But removing it
abruptly is not a solution, of course.

IMHO … it was one of the bests decisions.
The package filesystem is still existent … it it not pre-installed by
default. You can use it if you want!

The package installer ‘qnxinstall’ remains uneffected …

What’s the problem?

Armin


But then again QNX has long track
record of forcing their own interpretation of what’s best for customers onto
their customers. Nothing to be surprized about.

“Alain Bonnefoy” <> alain.bonnefoy@rieter.com> > wrote in message
news:ct5hjc$1e0$> 1@inn.qnx.com> …

Hi,
I’d like to have the feeling from the community about the 6.3 version,
because according to my tries from the month of June up today with Eclipse
and other changes came with this version, I’m still wondering if I stay to
6.2 or if I switch to 6.3.

For me:

The only reason to switch to 6.3 is the improvements done about Photon
developments.

The main problems are:

  1. The difference between the project management between the recursive
    makefiles and Eclipse.
    The unability to create nested projects within Eclipse is not only a
    problem of clearness in a project’s architecture but a real difficulty to
    maintain the dozens of projects based on the recursive makefiles method.
    Ok we can declare a traditional ‘C’ project an decide to not being able to
    use all wizard’s options setting.
    Convert the project? because of the PE price, we are maybe not ready to
    give a PE to each developper!

  2. The packages; this is certainly the most obvious contradiction in this
    6.3.
    New qnxinstall with features claim this their disappearence in 6.1 and we
    are still waiting for the dependency list we had before!!!
    New cl-installer features we claimed (me between others) in 6.2.
    New feature to use the packages without the package filesystem.

but in fact, QSSL decided to no more use the packages.

Anyone complained about fs-pkg problems or instability ?

I use fs-pkg on a server for 5 years 6.0 6.1 6.2 and on several targets
were I install/deinstall/copy/remove/create WITHOUT ANY PROBLEM!!!

And now?
when I develop executables, libraries, headers, etc…
How do I install it on other QNX hosts?
How do I install it on XP hosts?
Shell scripts? the same between QNX and Windows?
tar, zip? the same between QNX and Windows?
How can I know which version of any module a user use to build its
program?
How can I install the modules, configuration files, etc… on a customer
target?
How can I know which version this customer uses?
How can I know that a file has been modified from the base installation?

Ok, today qnxinstall seems to not taking care of QNX_TARGET/QNX_HOST but
from my point of view, packages are the only answer to these questions!!!

I think I know the answer from Armin > :wink: > but I’m absolutely not ready to
use rpm. QNX packages exists, qnxinstall exists (QNX and Windows at
least), cl-installer exists, fs-pkg exists and they just have to be
updated to work with the 6.3.

Finally I want to complain about the QSSL policy which decides to remove
features without taking care about their customers point of view. And I
don’t want to discuss about core, tools or I don’t know what else. For me,
packages is a feature, a REALLY necessary feature, available from the
beginning of QNX 6, and even if QSSL decided to no more use it for its
core components (which is, from my point of view not a good idea) I can’t
understand they could decide that everybody has to forget it!!

I waiting for your opinions.

Alain.


\

5

In fact, I complain also about the multiplication of channels because in
fact,

What do you suggest be done about that?

6

Mario Charest wrote:


In fact, I complain also about the multiplication of channels because in
fact,

What do you suggest be done about that?

Hi Mario,
I don’t know and in fact I just establish the fact.
I can understand that everybody could have its own affinities for one web
site or another, but I wonder if the most important thing for us is not to
know where we can be sure to find an answer about a problem.

regards,