Design Decision - Update and Upgrade System

[Murdock]

All - I'm looking at the code under LMCEUpdate* : http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/Update


It looks like the system was built around the MCE devs providing an xml file, sample here:

Code: [Select]

<?xml version="1.0"?>
<lmce_update>
 <update id="1">
  <description>Update mythtv packages from the Core to work with SchedulesDirect.</description>
  <priority>1</priority>
  <model>LMCE_CORE_1_1</model>
  <file
           URL="http://updates.linuxmce.com/update001.tar"
   action="untar"
   destination="/tmp/update001"
   md5="e9f1cf48cc688bbb223981d0df4e52f1"
   size="413168"
   autoexec="/tmp/update001/install-update.sh"
   />
 </update>

Today I'm thinking we've moved away from this model and are pushing all updates through standard apt processes. At this point do we want to abandon this XML process in favor of being able to upgrade and notify end users through the standard APT process, or do we want to keep going down the XML road?

[Marie.O]

The disadvantage of the xml process is, that it has to be maintained manually by us.

The xml process has the advantage, that one can control what updates are really being presented to the unsuspecting enduser. Sometime, a simple apt-get upgrade or apt-get dist-upgrade can be recipe for desaster (dist-upgrade more so than a regular upgrade).

I am in favor to keep the xml process, and let people, who use the commandline anyhow, use the apt-get procedure.

[Murdock]

I agree with the dist-upgrade - though why not link the 'upgrade now' button under the advanced menu to do an update/upgrade for the user? Currently the code is pointing to a shell script which doesn't exist. I'm thinking if we repoint it to a script, like this one: http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/lmce-upgrade/mkr_postinst.sh and make it reside in /usr/pluto/bin, and add code for the core.

[Murdock]

Ok, I've been testing with code attached to this trac ticket:
http://svn.linuxmce.org/trac.cgi/ticket/1399

I've also attached a log. I've been testing running this via the OSD orbiter by simply placing the file that the 'force upgrade now' button is expecting, which is also how I got the log.


What are our thoughts on implementing this as part of the base? I'd love to be able to use this personally.

Note: it uses upgrade and not dist-upgrade

[Marie.O]

As I said above: We have had problems in the past with apt-get upgrading. We have upstream repos which we can't control. I don't want things like the kdm issue people have experienced happen from the Orbiter UI. imho we should keep the update.xml and link that to Orbiter UI. People who want apt-get upgrades can do so from the commandline (or KDE).

[l3mce]

I have a ticket somewhere where I began work on a global upgrade, meaning it would update/upgrade the core and all MDs whether on and in use or off. As usual I had difficulty finding people to test, but remember it working correctly on my end. I will try and dig it up.


There it is.
http://svn.linuxmce.org/trac.cgi/ticket/341


I remembered doing some testing with dist-upgrading as well, but looking through this, it is just a regular upgrade.

[Murdock]

I've closed my ticket as I didn't know this one existed!

[DragonK]

I have a ticket somewhere where I began work on a global upgrade, meaning it would update/upgrade the core and all MDs whether on and in use or off. As usual I had difficulty finding people to test, but remember it working correctly on my end. I will try and dig it up.


There it is.
http://svn.linuxmce.org/trac.cgi/ticket/341


I remembered doing some testing with dist-upgrading as well, but looking through this, it is just a regular upgrade.

L3mce,

IF I understand correctly, the long and short of it is:
Upgrade the core, then the MD's would upgrade from the core's repository and not online repositories?
Thus cutting down on th eamount of data that needs to be downloaded?

Karel

[l3mce]

L3mce,

IF I understand correctly, the long and short of it is:
Upgrade the core, then the MD's would upgrade from the core's repository and not online repositories?
Thus cutting down on th eamount of data that needs to be downloaded?

Karel

Yes. Except for any packages that might be specific to the MD, everything upgrades locally.

However Possy has pointed out that when upstream changes break things (like mythtv, asterisk etc), this procedure breaks everything, and we should work on the xml updater. You are free to use this, but it will not be implemented as the default behavior for "force upgrade". It is pretty convenient though.

I should also be doing kernel version checking prior to upgrade commits, as there are weirdo systems out there which have different distro MDs and such.

[l3mce]

I know I said I wouldn't broach it again... yet here I am.

I just wanted ask about the behavior of my global upgrader... IF it does:

1 a core upgrade
2 copies all packages in /var/cache/apt/archive and /pluto/deb-cache to an accessable directory
3 does a scan packages to create Packages.gz
4 tars /usr/pluto/diskless
5 rsh/chroot into MD
6 Kernel check against core
7 backs up and overwrites sources.list to upgrade locally
8 upgrades self from core
9 rinse (cleanup/restore/backout on error)
10 repeats 5-10

Are you still terribly opposed to it?

[Murdock]

I think your question was for posde - though I'm all for it!

[Marie.O]

And I already talked to l3 in irc about it, and naying it