2.0. Normal package is mark as uninstalled when uninstall an upgrade package

[davidhs]

I have two packages:

Normal package:

Code Select Expand

<?xml version="1.0"?>
<!DOCTYPE package-info SYSTEM "http://www.simplemachines.org/xml/package-info">
<package-info xmlns="http://www.simplemachines.org/xml/package-info" xmlns:smf="http://www.simplemachines.org/">
<id>davidhs:my_id</id>
<name>my_name</name>
<version>v1</version>
<type>modification</type>

<install for="...">...</install>
<uninstall for="...">...</uninstall>
</package-info>

Upgrade package:

Code Select Expand

<?xml version="1.0"?>
<!DOCTYPE package-info SYSTEM "http://www.simplemachines.org/xml/package-info">
<package-info xmlns="http://www.simplemachines.org/xml/package-info" xmlns:smf="http://www.simplemachines.org/">
<id>davidhs:my_id</id>
<name>my_name</name>
<version>v1 upgrade1</version>
<type>modification, language,...</type>

<upgrade from="v1" for="...">...</upgrade>
<uninstall for="...">...</uninstall>
</package-info>

I do these steps
#1. Install normal package... ok
#2. Install upgrade package... ok
#3. Uninstall upgrade package... fail

After steps #3 upgrade is uninstalled (ok) but normal package is mark as... uninstalled (fail) (but really is installed)

In 2.0 RC3 this work, but in 2.0 RC4 was made a minor change or bugfix

Code Select Expand

SMF 2.0 RC4

June 2010
--------------------------------------------------------------------------------
! Uninstalling an upgrade did not set older versions as uninstalled. (Packages.php) [Bug 925]

and I think is a mistake, because if I uninstall an upgrade, I only want uninstall this, not normal packages.

File: Sources\Packages.php
Function: PackageInstall()

Line 978

Code Select Expand

SELECT package_id, install_state, db_changes
Must be:

Code Select Expand

SELECT id_install, install_state, db_changes

Line 1002

Code Select Expand

WHERE package_id = {string:package_id}',
Must be:

Code Select Expand

WHERE id_install = {int:install_id}',

Line 1007

Code Select Expand

'package_id' => $row['package_id'],
Must be:

Code Select Expand

'install_id' => $row['id_install'],

[kat]

You're referring, there, to RC3 and RC4.

RC= "Release candidate". i.e. "Not finished".

Have you looked at SMF v2 Final? It may have already been fixed.

[emanuele]

Nope K@.

The behaviour requested WAS the bug to fix.
Reading the bug report, the point is that the mod upgrader package must contain the uninstall for the entire mod and not only for the upgrade (that it does make sense since once the "upgrade" is installed the mod is in fact a different version).

davidhs as far as I understand, there are two different situations that cannot be distinguished with the current implementation of the package manager.
The first is:
1) pack1 version 1 (contains <install> and <uninstall>)
2) pack1 version 1.1 (contains <install>, <upgrade> and <uninstall>)
The second is:
1) pack1 version 1 (contains <install> and <uninstall>)
2) pack1 version 1.1 (contains <upgrade> and <uninstall>)

In the first scenario you apply pack1 at v1, than you apply pack1 at v1.1.
In v1.1 you have the instructions for the full install, for the upgrade and for the uninstall. Of course in that case, since v1.1 contains the instructions for full install it must contain also the instructions for a full uninstall, not only for the upgrade (because it can be applied directly as an "install package").
In that case if you apply v1 and v1.1, when you uninstall v1.1 you must set v1 as uninstalled.

In the second scenario (that is the one you are describing) you apply pack1 v1 and then pack1 v1.1.
In v1.1 you have only the upgrade instruction and then you expect the uninstall instructions only for the upgrade.

"Unfortunately" the current package manager cannot distinguish  between the two scenarios and then the developers had to take a decision and decided to go with scenario 1. That does make sense because the upgrade instructions are just something to avoid admins to uninstall the package before installing the upgraded version.

So the uninstall must be for the entire mod and not only for the upgrade.

[feline]

This package nanager function is changed since 2.0 RC5.
If you have upgrade packages, these MUST have the uninstall code for the entire mod ...

But one bug is exist and not fixed yet ...
If you have on the first package database changes and then you install a update, on uninstall the database changes can't remove. Same problem for changes on additional themes. THAT IS A BUG ...

[kat]

Nope K@.

You obviously understood FAR more of the post than I did, mate.

[emanuele]

Don't know, I'm doing too many things at the same time right now (and 3 of them are cheating with my CV... ) and I'm not always sure of what I write.

[davidhs]

You're referring, there, to RC3 and RC4.

RC= "Release candidate". i.e. "Not finished".

Have you looked at SMF v2 Final? It may have already been fixed.

It is for 2.0 final (and RC4, RC5, of course).

Nope K@.

The behaviour requested WAS the bug to fix.
Reading the bug report, the point is that the mod upgrader package must contain the uninstall for the entire mod and not only for the upgrade (that it does make sense since once the "upgrade" is installed the mod is in fact a different version).

davidhs as far as I understand, there are two different situations that cannot be distinguished with the current implementation of the package manager.
The first is:
1) pack1 version 1 (contains <install> and <uninstall>)
2) pack1 version 1.1 (contains <install>, <upgrade> and <uninstall>)
The second is:
1) pack1 version 1 (contains <install> and <uninstall>)
2) pack1 version 1.1 (contains <upgrade> and <uninstall>)

In the first scenario you apply pack1 at v1, than you apply pack1 at v1.1.
In v1.1 you have the instructions for the full install, for the upgrade and for the uninstall. Of course in that case, since v1.1 contains the instructions for full install it must contain also the instructions for a full uninstall, not only for the upgrade (because it can be applied directly as an "install package").
In that case if you apply v1 and v1.1, when you uninstall v1.1 you must set v1 as uninstalled.

In the second scenario (that is the one you are describing) you apply pack1 v1 and then pack1 v1.1.
In v1.1 you have only the upgrade instruction and then you expect the uninstall instructions only for the upgrade.

"Unfortunately" the current package manager cannot distinguish  between the two scenarios and then the developers had to take a decision and decided to go with scenario 1. That does make sense because the upgrade instructions are just something to avoid admins to uninstall the package before installing the upgraded version.

So the uninstall must be for the entire mod and not only for the upgrade.

Then in my scenario I can not use upgrade, but... how can I do this?

1. I have my (own) MOD only with english language
    pack1 version 1 (contains <install> and <uninstall>)

2. somebody translate my MOD to language1&2. I create other package only with two new languages, instead of create a new version on my MOD:
    pack2 version 1.lang1 (contains <upgrade from="1"> and <uninstall>; this only install/uninstall languages and require before install pack1)

3. somebody translate my MOD to language3. I create other package only with three languages, instead of create a new version on my MOD:
    pack3 version 1.lang2 (contains <upgrade from="1"> and <uninstall>; this only install/uninstall languages and require before install pack1)

4. I do a new version of my main package and language package
    pack4 version 2 (contains <install> and <uninstall>)
    pack5 version 2.lang1 (contains <upgrade from="2"> and <uninstall>; this only install/uninstall languages and require before install pack4)

etc.

Really, language package not is an upgrade, but I use this for write the FROM attribute (each language packaque only is valid for one version of my MOD).

Exists other way to do this?`Or I only can use normal install?

[davidhs]

Perhaps is necesary an un-upgrade tag?

This uninstall all: <upgrade>  <uninstall>
This only uninstall upgrade: <upgrade> <un-upgrade>

[emanuele]

1. I have my (own) MOD only with english language
    pack1 version 1 (contains <install> and <uninstall>)

2. somebody translate my MOD to language1&2. I create other package only with two new languages, instead of create a new version on my MOD:
    pack2 version 1.lang1 (contains <upgrade from="1"> and <uninstall>; this only install/uninstall languages and require before install pack1)

3. somebody translate my MOD to language3. I create other package only with three languages, instead of create a new version on my MOD:
    pack3 version 1.lang2 (contains <upgrade from="1"> and <uninstall>; this only install/uninstall languages and require before install pack1)

4. I do a new version of my main package and language package
    pack4 version 2 (contains <install> and <uninstall>)
    pack5 version 2.lang1 (contains <upgrade from="2"> and <uninstall>; this only install/uninstall languages and require before install pack4)

That wont work either.
Assume I install your mod at version 1. Than you provide a new language with a separated pack and I need it, w00t!! Let's install it, the  mod is now at version 1.1. Few days later you release another "language pack" and hey I need that too! <upgrade from="1"> it won't install because now my mod is already at version 1.1...
And even if you provide 2 "<upgrade from>" to install different language packs it will be mandatory to follow the "release order", other wise you would have to re-release every time all your lang-packs with all the possible <upgrade from> combinations.

The only solution is to provide a new release with (incremental) upgrade instructions in there (that is the way the PM is supposed to work).
AFAIK the package manager is simply not intended to work that way, that's the point.

But let's leave the topic here, maybe a dev comes through and find a solution.


ops...I though I posted this but I found it floating around in a tab...oh well at least I didn't delete it!

[davidhs]

Really, a person only install one language pack, i.e if he is Portuguese, do this.

1. I create normal pack 1 and language pack 1.1 with French.
    He only install normal pack

2. I create language pack 1.2 with French and Italian.
    He install nothing

3. I create language pack 1.3 with French, Italian and Portuguese.
    He install language 1.3

4. I create language pack 1.4 with French, Italian, Portuguese and Russian.
    He install nothing

5. I create normal pack 2 and language pack 2.1 with French, Italian, Portuguese and Russian.
    He uninstall language pack 1.3 and normal pack 1
    He install normal pack 2 and language pack 2.1

[emanuele]

Really, a person only install one language pack, i.e if he is Portuguese, do this.

Why?
If I run a forum with more than one language?
But probably that's not the point.

As I said: at the moment this is not the way the package manager is meant to work, so this could not be considered a bug, more a feature request.
Please read the comments for the issue I linked before and in particular SiNaN's comment.

But one bug is exist and not fixed yet ...
If you have on the first package database changes and then you install a update, on uninstall the database changes can't remove. Same problem for changes on additional themes. THAT IS A BUG ...

Is this already reported in mantis?
Is there a known fix? If no, do you have a demo package (and relative upgrade) or an example I can play with? (not sure to be able to provide something, but I like to play with this kind of things... )

[feline]

But one bug is exist and not fixed yet ...
If you have on the first package database changes and then you install a update, on uninstall the database changes can't remove. Same problem for changes on additional themes. THAT IS A BUG ...

Is this already reported in mantis?
Is there a known fix? If no, do you have a demo package (and relative upgrade) or an example I can play with? (not sure to be able to provide something, but I like to play with this kind of things... )

Not reported yet.
For the missig theme changes we have made follow fix, the database code changes we handle in out installer itself.

Code Select Expand


<file name="$sourcedir/Packages.php">
<operation>
<search position="replace"><![CDATA[
// See if this is already installed, and change it's state as required.
$request = $smcFunc['db_query']('', '
SELECT package_id, install_state, db_changes
FROM {db_prefix}log_packages
WHERE install_state != {int:not_installed}
AND package_id = {string:current_package}
]]></search>
<add><![CDATA[
// See if this is already installed, and change it's state as required.
$request = $smcFunc['db_query']('', '
SELECT package_id, install_state, db_changes, themes_installed
FROM {db_prefix}log_packages
WHERE install_state != {int:not_installed}
AND package_id = {string:current_package}
]]></add>
</operation>

<operation>
<search position="replace"><![CDATA[
// Otherwise must be an upgrade.
else
{
$is_upgrade = true;
$old_db_changes = empty($row['db_changes']) ? array() : unserialize($row['db_changes']);
}
]]></search>
<add><![CDATA[
// Otherwise must be an upgrade.
else
{
$is_upgrade = true;
$old_db_changes = empty($row['db_changes']) ? array() : unserialize($row['db_changes']);
$themes_installed = array_merge($themes_installed, explode(',', $row['themes_installed']));
}
]]></add>
</operation>
</file>


[davidhs]

I write a request about this:

http://www.simplemachines.org/community/index.php?topic=451653.0

[Illori]

is this something we want to look into further developers?

[Arantor]

I do not want to encourage the use of upgrade packages. While it's a nice idea in theory, few enough people use what there is, and too many mods will break even if it is used that I can't encourage it being used at all.

Honestly, I'm tempted to remove the functionality at all because it's never been reliable enough to actually *use*.

[davidhs]

In my MODs I have never used.

Just see it useful to add languages ​​without creating a new version of the mod ... but can not be used for that. 

[Arantor]

Yup, it needs a redesign of the package manager to be able to be useful.