I believe creating a package via APM is consistent with retrieving packages from other locations, such as via CVS. Creating the package via APM creates the files and directories that are the framework for the package.
The next steps are:
2. "install" the package, which requires a server restart.
3. "mount" package in site-map (depending on package)
Separating the processes in this way allows multiple packages to be created with only one server restart, and helps to keep package generation consistent, since there is only one process for installing packages instead of two.
OK, good enough, that makes sense...
So could someone alter the APM so it mentions that they will have to restart?
1. The package version is set up and marked enabled and installed.
2. You go to the "install packages" acs-admin page, and the package does not show up.
3. Apparently it is half-installed/half-not installed.
4. The reason is that no apm_package_type is created for the package, so it's in a semi-zombie state (this is why you can't install it, and if it allowed you to install it, it would scream because the version already exists!)
Jim, you can test this by going to psql and giving this command:
select * from apm_package_versions where package_key = 'your-package-key';
select * from apm_package_types where package_key = 'your-package-key'.
Torben, please remove your misleading change to the HTML page.
It would require a rewriting of the entire APM to get rid of this "install package upon creation" bit, because add depedencies, parameters, etc are all driven by the package version's params etc as stored in the database (not the XML info file).
So the right thing to do is to make the new package fully installed, as gross as that is, and I will do so this weekend, by making an entry in apm_package_types for the new package when it is created.
I tried to be as specific as possible with the revised language by describing the actual actions taken, and suggesting a server restart to complete the install.. until a core developer could revise it appropriately.
The language change seems appropriate for the circumstances until a fix is made; and a fix should include revising it.
I have realized this behavior a while ago. It got me confused at first. I believe this started in the oacs 5.4 core.
I quite remember old versions of oacs worked fine. It means right after creating a package on APM, the package was showed in the list and the new package was possible to be mounted without restart the system.
I am not saying which one, new or past behavior, is the correct one. I just would like to understand why to restart the system is needed (because it is a bit confusing). And why it wasn't necessary in the old versions.
it would be great (if really needed), that restarting was forced by the system. Then misunderstanding or "misleadings" will be gone for good!
Please remove the text.
As far as being able to read the minds of core developers, this code goes all the way back to something like ACS 3.5, at Ars Digita. Personally I think it's a poor implementation choice, but without a complete rewrite of the APM it's the implementation choice we're going to have to live with. The failure to create a package type for the new package is a bug, pure and simple, and will be fixed.
1. bugs like this will be avoided,
2. standard workflow is re-enforced,
3. admins won't be forced to install an empty package whenever they create a new one.
Does the apm_package_type mean (for now) service or app?
no apm_package_type is created for the packageYes it is, just tested in 5.5. I'll be posting a log. Here is the log: http://jam.sessionsnet.org/files/download/package-error-log.txt?file_id=5669