-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi everybody! Now that I am close to starting a new stable series with Wesnoth I came across a small problem with the way versions currently work in PXML. For this let me explain a little first:
In Wesnoth we use two series in parallel. One is the stable series (currently 1.8.x), the other is the development series (currently 1.9.x). Eventually the development series becomes the new stable series (in this case 1.9.x will become 1.10.x). The main difference between those two versions is that the stable series is significantly better for MP players due to having more players on the server and it being a stable base for a while so that users can adjust to balancing changes. The dev series on the other hand is often better for people playing singleplayer in english and wanting all the latest bling.
So, now the problem: How to approach the upgrade from 1.9.14 to 1.10.0? In theory this is a direct upgrade. Though not only users of 1.9.x should update to 1.10.0 but also users of 1.8.x. Basically there are two package ids at the moment which would both become obsolete with the new series: wesnoth-1.8 as well as wesnoth-1.9. In theory I could probably continue using the wesnoth-1.9 user data dir for 1.10 but would, because of this, also keep the package id. But how should 1.8.x users be made aware of the update eg via the repo or package manager?
This is where my proposal comes into the picture:
What would be required here is some "recommended_upgrade" tag listing (explicit) ids which should be replaced by this package. The tag would probably be part of the <package> block and is because of this only relevant for repositories and package managers. The syntax could look like this:
<package id="new_uniqueID"> (..) <recommended_upgrades> <package_id="old_uniqueID" /> <package_id="old_uniqueID2" /> </recommended_upgrades> </package>
In this example the package "new_uniqueID" would recommend an update to it in case either a package with "old_uniqueID" or "old_uniqueID2" is found. So replacing several packages would be possible. Use cases for this tag is what I listed above as well as cases where the old maintainer of a package is completely gone and someone new is taking over eg the development of an emulator.
In case a package is detected which asks to update other packages the interface would somehow display that it can update the now outdated packages and the user is to be asked if packages should be replaced with this new package (so basically an optional upgrade path).
Implementation of this would not have to happen in libpnd itself but in eg the repo as well as package managers. Open questions include how to best handle appdata of the replaced packages. I don't have a nice solution for this though. Here I'd simply go for "use the appdata the new application now provides".
Comments? Feedback? Am I missing anything important?
Cheers, Nils Kneuper aka Ivanovic
If this is integrated into an auto-update facility, it creates a door which less than scrupulous people can use to create a package that claims to be an upgrade to everything, thus wiping out everything. Other than that, I think it's a great idea. Making sure that door remains locked should not be exceptionally difficult: one naive approach is, if it upgrades something in this way, an auto-update facility says "X would like to upgrade Y and Z. Is this OK?" and leave it on the user to realize that "SuperGamePlus" really shouldn't be updating 120 different PNDs. I'm sure there's some sanity checks the repo can do when something is uploaded as well
On Thu, Jan 19, 2012 at 8:14 AM, Nils Kneuper crazy-ivanovic@gmx.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi everybody! Now that I am close to starting a new stable series with Wesnoth I came across a small problem with the way versions currently work in PXML. For this let me explain a little first:
In Wesnoth we use two series in parallel. One is the stable series (currently 1.8.x), the other is the development series (currently 1.9.x). Eventually the development series becomes the new stable series (in this case 1.9.x will become 1.10.x). The main difference between those two versions is that the stable series is significantly better for MP players due to having more players on the server and it being a stable base for a while so that users can adjust to balancing changes. The dev series on the other hand is often better for people playing singleplayer in english and wanting all the latest bling.
So, now the problem: How to approach the upgrade from 1.9.14 to 1.10.0? In theory this is a direct upgrade. Though not only users of 1.9.x should update to 1.10.0 but also users of 1.8.x. Basically there are two package ids at the moment which would both become obsolete with the new series: wesnoth-1.8 as well as wesnoth-1.9. In theory I could probably continue using the wesnoth-1.9 user data dir for 1.10 but would, because of this, also keep the package id. But how should 1.8.x users be made aware of the update eg via the repo or package manager?
This is where my proposal comes into the picture:
What would be required here is some "recommended_upgrade" tag listing (explicit) ids which should be replaced by this package. The tag would probably be part of the <package> block and is because of this only relevant for repositories and package managers. The syntax could look like this:
<package id="new_uniqueID"> (..) <recommended_upgrades> <package_id="old_uniqueID" /> <package_id="old_uniqueID2" /> </recommended_upgrades> </package>
In this example the package "new_uniqueID" would recommend an update to it in case either a package with "old_uniqueID" or "old_uniqueID2" is found. So replacing several packages would be possible. Use cases for this tag is what I listed above as well as cases where the old maintainer of a package is completely gone and someone new is taking over eg the development of an emulator.
In case a package is detected which asks to update other packages the interface would somehow display that it can update the now outdated packages and the user is to be asked if packages should be replaced with this new package (so basically an optional upgrade path).
Implementation of this would not have to happen in libpnd itself but in eg the repo as well as package managers. Open questions include how to best handle appdata of the replaced packages. I don't have a nice solution for this though. Here I'd simply go for "use the appdata the new application now provides".
Comments? Feedback? Am I missing anything important?
Cheers, Nils Kneuper aka Ivanovic -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk8YFz4ACgkQfFda9thizwUfuQCgmNKDLFqI4Hh69CABANqZ7/1E d4AAoI2+9Ys8JqUF64u3LAdo1/uNIB1C =JYS0 -----END PGP SIGNATURE----- _______________________________________________ Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 19.01.2012 14:43, schrieb David Goldsmith:
If this is integrated into an auto-update facility, it creates a door which less than scrupulous people can use to create a package that claims to be an upgrade to everything, thus wiping out everything. Other than that, I think it's a great idea. Making sure that door remains locked should not be exceptionally difficult: one naive approach is, if it upgrades something in this way, an auto-update facility says "X would like to upgrade Y and Z. Is this OK?" and leave it on the user to realize that "SuperGamePlus" really shouldn't be updating 120 different PNDs. I'm sure there's some sanity checks the repo can do when something is uploaded as well
Exactly that is what I meant with "ask the user and just propose this as upgrade". So it is of course the users decission if they want to do it or not. Of course you are right that some sanity checks in eg the repo also make sense to make sure that eg not more than 5 or 10 packages (sane numbers are to be determined later on!) are replaced.
Cheers, Nils Kneuper aka Ivanovic
Could we not look at some sort of code signing in the PXML? For example, have a site as a "trusted authority", then PXMLs get signed by their developers. Downloads could be validated against the trusted authority
Maybe overkill, but just a thought
Thursday, January 19, 2012, 1:52:10 PM, you wrote:
NK> -----BEGIN PGP SIGNED MESSAGE----- NK> Hash: SHA1
NK> Am 19.01.2012 14:43, schrieb David Goldsmith:
If this is integrated into an auto-update facility, it creates a door which less than scrupulous people can use to create a package that claims to be an upgrade to everything, thus wiping out everything. Other than that, I think it's a great idea. Making sure that door remains locked should not be exceptionally difficult: one naive approach is, if it upgrades something in this way, an auto-update facility says "X would like to upgrade Y and Z. Is this OK?" and leave it on the user to realize that "SuperGamePlus" really shouldn't be updating 120 different PNDs. I'm sure there's some sanity checks the repo can do when something is uploaded as well
NK> Exactly that is what I meant with "ask the user and just propose this as NK> upgrade". So it is of course the users decission if they want to do it or not. NK> Of course you are right that some sanity checks in eg the repo also make sense NK> to make sure that eg not more than 5 or 10 packages (sane numbers are to be NK> determined later on!) are replaced.
NK> Cheers, NK> Nils Kneuper aka Ivanovic NK> -----BEGIN PGP SIGNATURE----- NK> Version: GnuPG v2.0.18 (GNU/Linux)
NK> iEYEARECAAYFAk8YIAoACgkQfFda9thizwXL/ACgiehZGLP6fFZBVBbnJidKkPek NK> Be8Anipmu3Uv1IFNHHjFxAh4ebUfesEL NK> =X/gz NK> -----END PGP SIGNATURE----- NK> _______________________________________________ NK> Firmware-dev mailing list NK> Firmware-dev@openpandora.org NK> http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
Could we not look at some sort of code signing in the PXML? For example, have a site as a "trusted authority", then PXMLs get signed by their developers. Downloads could be validated against the trusted authority
Maybe overkill, but just a thought
Note to mods: I accidently sent this the first time from the wrong email account, you can ignore one of these mails. Sorry about that
Thursday, January 19, 2012, 1:52:10 PM, you wrote:
NK> -----BEGIN PGP SIGNED MESSAGE----- NK> Hash: SHA1
NK> Am 19.01.2012 14:43, schrieb David Goldsmith:
If this is integrated into an auto-update facility, it creates a door which less than scrupulous people can use to create a package that claims to be an upgrade to everything, thus wiping out everything. Other than that, I think it's a great idea. Making sure that door remains locked should not be exceptionally difficult: one naive approach is, if it upgrades something in this way, an auto-update facility says "X would like to upgrade Y and Z. Is this OK?" and leave it on the user to realize that "SuperGamePlus" really shouldn't be updating 120 different PNDs. I'm sure there's some sanity checks the repo can do when something is uploaded as well
NK> Exactly that is what I meant with "ask the user and just propose this as NK> upgrade". So it is of course the users decission if they want to do it or not. NK> Of course you are right that some sanity checks in eg the repo also make sense NK> to make sure that eg not more than 5 or 10 packages (sane numbers are to be NK> determined later on!) are replaced.
NK> Cheers, NK> Nils Kneuper aka Ivanovic NK> -----BEGIN PGP SIGNATURE----- NK> Version: GnuPG v2.0.18 (GNU/Linux)
NK> iEYEARECAAYFAk8YIAoACgkQfFda9thizwXL/ACgiehZGLP6fFZBVBbnJidKkPek NK> Be8Anipmu3Uv1IFNHHjFxAh4ebUfesEL NK> =X/gz NK> -----END PGP SIGNATURE----- NK> _______________________________________________ NK> Firmware-dev mailing list NK> Firmware-dev@openpandora.org NK> http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
On Thu, 19 Jan 2012, Nils Kneuper wrote:
# In Wesnoth we use two series in parallel. One is the stable series (currently
Permit me to be dense tonight (again); got a upset baby here and not much sleep in about.. oh, 4 months ;)
# 1.8.x), the other is the development series (currently 1.9.x). Eventually the # development series becomes the new stable series (in this case 1.9.x will # become 1.10.x). The main difference between those two versions is that the
okay so you're doing even/odd stable/dev versionin
stable == 1.6 -> 1.8 -> 1.10 -> .. dev == 1.5 -> 1.7 -> 1.9 -> 1.11 ..
The pnds are presumably flagged as production ready and beta as appropriate.
# stable series is significantly better for MP players due to having more # players on the server and it being a stable base for a while so that users can # adjust to balancing changes. The dev series on the other hand is often better # for people playing singleplayer in english and wanting all the latest bling. # # So, now the problem: # How to approach the upgrade from 1.9.14 to 1.10.0? In theory this is a direct # upgrade. Though not only users of 1.9.x should update to 1.10.0 but also users # of 1.8.x. Basically there are two package ids at the moment which would both # become obsolete with the new series: wesnoth-1.8 as well as wesnoth-1.9. In # theory I could probably continue using the wesnoth-1.9 user data dir for 1.10 # but would, because of this, also keep the package id. But how should 1.8.x # users be made aware of the update eg via the repo or package manager?
I'm sort of confused here -- wheres the problem? Can you spell it out?
I don't know how the repos and pndstore and etc handle it now, but I'm guessing one of two ways..
i) blind trust on version numbering In this case, 1.10 is higher than 1.8 and 1.9, so both versions would show as an upgrade; this is a problem during the lifecycle perhaps (since 1.9 dev woudl show up as advancement on 1.8 stable), but the users must already be aware of this or you'd have brought it up before? 1.10 isn't the problem here.
ii) they use version, but track it in terms of phase; ie: prod to prod, and beta to beta, that sort. In this case, 1.8 is upgraded to 1.10 == good 1.9 is not upgraded to 1.10 == you know, thats not bad either ie: If user wants to track prod he can track prod; he can track dev; he can track both; really, if he's tracking 1.9 dev, then when 1.10 prod goes out, probabyl 1.11 dev starts right away anyway? so he'd want to go from 1.9 to 1.11 dev to dev anyway? --> so, this is not so bad?
Or do you want to explicitly say 'ignore phase, always go with version number'?
Or do you want to handle something exotic like 'this pckage is an upgrade from 1.4, 1.8 to 2.6, but not from 1.5', or that sort?
But for _your_ scenario above, it seems like existing would work just fine?
Unless I don't know how the repos are showing upgrades -- which I do not :)
Just strikes me we can get by with version numberingm, not having to explitly say 'come from', or a chainm of 'come froms'?
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 20.01.2012 02:15, schrieb skeezix:
I'm sort of confused here -- wheres the problem? Can you spell it out?
I don't know how the repos and pndstore and etc handle it now, but I'm guessing one of two ways..
You musn't mix up two things: package id and version number of this specific package id. Yes, the version is *only* specific to one explicit package id. The first match done is always on the package id, only later on the version number is taken into account.
i) blind trust on version numbering In this case, 1.10 is higher than 1.8 and 1.9, so both versions would show as an upgrade; this is a problem during the lifecycle perhaps (since 1.9 dev woudl show up as advancement on 1.8 stable), but the users must already be aware of this or you'd have brought it up before? 1.10 isn't the problem here.
The matter is that version number matching only exists if the package id is identical. Due to the limitations of the pnd system (unique ids!) it would not be possible to have two packages with the same id but only differing version numbers on the pandora (aka stable and dev in parallel). So the result is/was that I had to introduce two differing ids (and using differing userdata folders, too): wesnoth-1.8 and wesnoth-1.9. Due to this there is no upgrade path available for at least one of the two packages.
ii) they use version, but track it in terms of phase; ie: prod to prod, and beta to beta, that sort. In this case, 1.8 is upgraded to 1.10 == good 1.9 is not upgraded to 1.10 == you know, thats not bad either ie: If user wants to track prod he can track prod; he can track dev; he can track both; really, if he's tracking 1.9 dev, then when 1.10 prod goes out, probabyl 1.11 dev starts right away anyway? so he'd want to go from 1.9 to 1.11 dev to dev anyway? --> so, this is not so bad?
It will take many months until 1.11.0 is released. And for this time the logical update from 1.9.14 *is* 1.10.0.
Or do you want to explicitly say 'ignore phase, always go with version number'?
Exactly. The basic choice for the user should not be the phase but which "version tree" they want.
Or do you want to handle something exotic like 'this pckage is an upgrade from 1.4, 1.8 to 2.6, but not from 1.5', or that sort?
Nothing exotic at all. Just "many" package ids being "outdated" due to the start of this new package series.
But for _your_ scenario above, it seems like existing would work just fine?
Unless I don't know how the repos are showing upgrades -- which I do not :)
They don't show upgrades since there is no way to define upgrades so far.
Just strikes me we can get by with version numberingm, not having to explitly say 'come from', or a chainm of 'come froms'?
Yes, it is fine as long as there is only one single package and the user not wanting to install several of those in parallel (which is likely to happen in case of wesnoth, there the users often want both, stable and dev).