[Dextrose] [PATCH] Fix for bugs sl#2713 and au#885.

[Aleksey Lim]

On Wed, Sep 14, 2011 at 11:42:19AM +0000, Aleksey Lim wrote:
> On Wed, Sep 14, 2011 at 04:00:25PM +0530, Anish Mangal wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 09/13/2011 01:29 AM, Aleksey Lim wrote:
> > > On Mon, Sep 12, 2011 at 12:35:17AM +0530, Ajay Garg wrote:
> > >> Running the "dextrose-updater" cron.daily job, "touches" a "/var/lib/dextrose-updater" file. This file is then used in the subsequent run, to determine if it
> > >> is ok to re-run the job. Effectively, the "last-touched-timestamp" value of "/var/lib/dextrose-updater" is made use of in the "dextrose-updater" job script.
> > >>
> > >> Used similar logic - used the "last-touched-time" as the time when the yum-updater was last run.
> > >>
> > >> Thanks to Anish, for some wonderful review feedback.
> > > 
> > > There are a couple of issues in the patch, but my concern is about
> > > not having all hardcoded stuf (not only for dextrose but, eg, for OLPC's
> > > XS) in shell code and relying only on command line API (the reason is
> > > that this command might be called w/o shell's UI at all and might have
> > > quite different release schedule in comapring w/ shell).
> > > 
> > > In other words, it will be useful to:
> > > 
> > > * rehash such code in Dextrose patch (for updater and school server backups)
> > > * rehash XS related code
> > > * create a Feature/ page on SL wiki for such refactoring/adding-new-code
> > > * in Feature's code, use sugar-client[1] command line API to all
> > >   interactions with [school] server (and hide such UI if sugar-client
> > >   command doesn't exist)
> > > 
> > > [1] http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-client
> > > 
> > 
> > Ajay, Perhaps we could simply use the 'yum history' command here. It would:
> > * Make the patch not depend on dextrose-updater
> > * Not do too many things in shell (except invoke yum history)
> > * yum is a critical and mature fedora component. It won't be too
> > volatile in terms of compatibility IMHO
> > 
> > Aleksey, I didn't fully understand your comment. In part, how is this
> > related to XS, particularly, the server side (maybe you're implying
> > sugar-client side here, but I'm not sure if that is ready to be included
> > in dx3 yet?).
> > 
> > The bug is a simple one: Find out when the yum updater last ran and
> > updated successfully. It most probably has value integrating it(finding
> > such info) into SSK client/server implementation following the approach
> > you mentioned. However, I would also like this to be working for current
> > dx3.
> 
> m_anish │ alsroot, thanks for reviewing ajay's patch on @dx :)
> alsroot │ m_anish: that wasn't a review, I just think that putting bunch of hardcoded stuff that relate to deployment workflow is
>         │ not the right way and needs to be hidden behind command line API
> m_anish │ alsroot, +1, on that particular patch perhaps, maybe just using yum history would work well... I replied to your email
>         │ btw.
> alsroot │ m_anish: my idea is that sugar should ask a cli (relying on its API), "get_last_update_time". thats all that sugar should
>         │ do (if cli tool exists)
> m_anish │ alsroot, +1, agree, i guess it would be good to have it as a part of sugar-client. until that ... 'yum history' followed
>         │ by 'python re' would work IMO
> m_anish │ alsroot, good morning, btw :)
> alsroot │ m_anish: morning, sugar should not rely on what pms is being used, thats the task of sugar-client internal impl
> m_anish │ alsroot, yup, that's why I used 'until that...' in my prev. comment
> m_anish │ alsroot, while we're discussing, perhaps would be good to know sugar-client impl roadmap?
> m_anish │ in particular, any chance of it going in dx3?
> alsroot │ m_anish: I'm going to use it in .py pilot program and as result, having it released in SSK-1.1 (1 dec)
> m_anish │ also need to consider that it may need to work in cases where the whole SSK is not being used?
> alsroot │ m_anish: ie, it can be a part of dx3
> alsroot │ m_anish: the whole idea behind SSK, is that it is not a final solution but a kit, ie, sugar-client can be used on its own
> m_anish │ alsroot, hmm... we don't plan to do any major changes to dx3 now besides what is captured in the feature freeze doc, 1dec
>         │ may be too late (maybe incorporating it in dx4 would be the way to go)
> m_anish │ alsroot, okay
> alsroot │ m_anish: in my mind having all these hard coded stuff is a really wrong way, eg, troubles w/ trying/not-trying to push it
>         │ to upstream
> alsroot │ and keeping in mind that dx3 might be supported for year/two is might be useful to get rid of these stuff in dx2
> m_anish │ alsroot, if its not too big a change, it should be easily doable (s/hardcoded/SSK_impl/) via the yum updater
> alsroot │ m_anish: the benefit of having this cli tool, is that sugar code will be pretty simple (thus, easy to keep it stable). the
>         │ logic will in that cli and can be improved in minor dx3 releases
> m_anish │ alsroot, i agree in principle on using SSK (cli-tool), but we need to have this working in our test releases, and I guess
>         │ cli-tool isn't ready yet?
> m_anish │ alsroot, I guess the bigger underlying question is whether we can have this by the time dx3 is released... or do this via
>         │ an update later (after testing it)
> alsroot │ m_anish: any way, in this particular case (w/ last update date), sugar code can already rely on external API

ie, http://wiki.sugarlabs.org/go/Sugar_Server_Kit/Client_API
The code in the Shell needs only to call `sugar-client --slave last-update`

-- 
Aleksey