dflemstr
It's a ball.
(tl;dr part below)
So, I was having thoughts about package management, PNDs and the like, thinking about how packages are to be managed on the Pandora.
As you might or might not know, the PXML format contains <version> information. Now, the sole purpose of versioning information in a package would be to make it upgradable, right? Why would you otherwise store information about versions in the package...
So, auto-upgrades for PND-packages would be pretty nifty.
And don't say that an auto-upgrade system for the Pandora would be impossible; I've tested package upgrades based on XML metadata already (see this) so it is possible.
Sounds perfect, right? You can download a PND, put it in some folder, and a daemon can scan your PND folders for you, and notify you of new upgrades for your packages. Awesome.
There's one slight problem preventing this, though (well, if you read the topic title you know there had to be a problem): even though versioning information is available, it is currently impossible to actually see if one package is the successor of another.
Why? Because there is no information available in the PXML format that actually tells us what "series" of packages the package belongs to.
In big package management systems such as RPM, etc, every package has a package identifier; "firefox" would for example be the identifier for Firefox, and "kdebase-runtime" would contain the KDE runtime libraries. It is then of course possible to upgrade these packages, since you just look for a package with the same name, and a higher version number, and replace the old package. This identifier, however, is not available int he current PXML format.
→→tl;dr part starts here (but it still is a lot of reading
)
Now, we have discussed this before (I wrote the whole introduction above just to inform uninformed people); we have discussed various definitions for the "id" attribute in the PXML tag that would enable us to avoid storage conflicts and introduce some kind of identification system, thus enabling us to do auto-updating etc. Such a definition was never created, though, and I think it's time to look into this now (because soon it will be too late).
The definition has to contain package identification data for an update system while still being changeable between versions for the persistent storage system.
My proposed standard for this id attribute would therefore be as follows:
Let's take an example: Someone wants to package Firefox (let's say, I do). I therefore create a PND with a PXML file containing the following ID:
CODE
firefox:dflemstr:1
...because the package is a "firefox" package, and it needs a new overlay (since it's the first release of the package) so I write my user name and the number 1 to identify this overlay.
Now, let's say that some releases later (note: the overlay won't change every version most probably!), I decide that Firefox needs a new overlay because of new configuration file formats etc. I then increase the overlay number like so:
CODE
firefox:dflemstr:2
And let's say that I am releasing a development version of Firefox every now and then (IRL I would name the package something else like "firefox-svn", so as to not trigger the auto-upgrade of everyone's stable firefox versions but this is hypothetical), and need a separate overlay for that. In that case I can simply add one by specifying some string that makes sense to me (it can be anything; it just has to be unique amongst my own overlay identifiers):
CODE
firefox:dflemstr:dev-1
...and when I release a new development version of Firefox that also needs a new overlay I can specify something else:
CODE
firefox:dflemstr:dev-2-experimental
etc.
Now, let's say that someone thinks I'm a lousy packager and wants to release his/her own version of Firefox, with a new overlay. Then this person creates a PND with the following ID:
CODE
firefox:somedude:whatever-53
...and thus no overlay collisions can occur!
If that user still remains compatible with the old overlay, he/she can of course use my old overlay by specifying my old ID attribute; you only have to change the attribute when you need a new overlay.
Opinions? Any flaws that I have missed?
So, I was having thoughts about package management, PNDs and the like, thinking about how packages are to be managed on the Pandora.
As you might or might not know, the PXML format contains <version> information. Now, the sole purpose of versioning information in a package would be to make it upgradable, right? Why would you otherwise store information about versions in the package...
So, auto-upgrades for PND-packages would be pretty nifty.
And don't say that an auto-upgrade system for the Pandora would be impossible; I've tested package upgrades based on XML metadata already (see this) so it is possible.
Sounds perfect, right? You can download a PND, put it in some folder, and a daemon can scan your PND folders for you, and notify you of new upgrades for your packages. Awesome.
There's one slight problem preventing this, though (well, if you read the topic title you know there had to be a problem): even though versioning information is available, it is currently impossible to actually see if one package is the successor of another.
Why? Because there is no information available in the PXML format that actually tells us what "series" of packages the package belongs to.
In big package management systems such as RPM, etc, every package has a package identifier; "firefox" would for example be the identifier for Firefox, and "kdebase-runtime" would contain the KDE runtime libraries. It is then of course possible to upgrade these packages, since you just look for a package with the same name, and a higher version number, and replace the old package. This identifier, however, is not available int he current PXML format.
→→tl;dr part starts here (but it still is a lot of reading
Now, we have discussed this before (I wrote the whole introduction above just to inform uninformed people); we have discussed various definitions for the "id" attribute in the PXML tag that would enable us to avoid storage conflicts and introduce some kind of identification system, thus enabling us to do auto-updating etc. Such a definition was never created, though, and I think it's time to look into this now (because soon it will be too late).
The definition has to contain package identification data for an update system while still being changeable between versions for the persistent storage system.
My proposed standard for this id attribute would therefore be as follows:
- The overlay/persistent storage system uses the whole id as its "hash value"; it doesn't have to care about the standard at all and just uses the whole id for overlay identification (→ we thus remain backwards-compatible as this is how the system looks like now! No code changes needed!)
- The id attribute is split up into three parts: "name:last-modifier:overlay-number":
- The name is the package identification name. This is the unique package name, like "firefox" or "kdebase-runtime" as explained above, thus enabling package upgrades.
- The last-modifier is the user name of the person that last changed the package so that it required a new overlay (explained below)
- The overlay-number is a number increased every time the application needs a new overlay. This doesn't have to be a number, but can be anything the author wants it to be. Explained below.
Let's take an example: Someone wants to package Firefox (let's say, I do). I therefore create a PND with a PXML file containing the following ID:
CODE
firefox:dflemstr:1
...because the package is a "firefox" package, and it needs a new overlay (since it's the first release of the package) so I write my user name and the number 1 to identify this overlay.
Now, let's say that some releases later (note: the overlay won't change every version most probably!), I decide that Firefox needs a new overlay because of new configuration file formats etc. I then increase the overlay number like so:
CODE
firefox:dflemstr:2
And let's say that I am releasing a development version of Firefox every now and then (IRL I would name the package something else like "firefox-svn", so as to not trigger the auto-upgrade of everyone's stable firefox versions but this is hypothetical), and need a separate overlay for that. In that case I can simply add one by specifying some string that makes sense to me (it can be anything; it just has to be unique amongst my own overlay identifiers):
CODE
firefox:dflemstr:dev-1
...and when I release a new development version of Firefox that also needs a new overlay I can specify something else:
CODE
firefox:dflemstr:dev-2-experimental
etc.
Now, let's say that someone thinks I'm a lousy packager and wants to release his/her own version of Firefox, with a new overlay. Then this person creates a PND with the following ID:
CODE
firefox:somedude:whatever-53
...and thus no overlay collisions can occur!
If that user still remains compatible with the old overlay, he/she can of course use my old overlay by specifying my old ID attribute; you only have to change the attribute when you need a new overlay.
Opinions? Any flaws that I have missed?
Last edited by a moderator: