dpkg packages has postinst and prerm scripts that get executed while
installing/removing package. It it hard to guess what they do (and
modify) so you may not know what exactly to backup and may loose some
effects of those scripts when restoring just the files from packages.
[...]
tarring whole disk will work. Backing up only rendom selected part not.
That's good. Anyway it seems I have not been able to explain exactly what
I'm asking, I'll try to be more clear: is it possible to backup *almost
all* the directories and files via ssh and tar, flash the device,
reinstall the ssh server and restore the backup'd stuff into the renewed
device, in order to have everything working again, good as before or
better, with minimum effort? (except some eventual bugs introduced with
the new firmware, of course)
With "almost all", really I mean *everything*, just excluding the
dirs/files that we should not backup because they're unnecessary (I don't
know: proc, lost+found, mnt, ...), and the dirs/files that we should not
backup because we want to keep the new ones (that is, the updated files
after the flash: we have to avoid backup and restore of the old ones,
otherwise we've lost our time ;)
From what has been said here on the list, I've seen why the approach of
rough overwrite via ssh cannot be chosen to directly update the files that
would be flashed with the flasher tool, but still it's not clear to me the
reason why we should not backup and restore "all the other stuff" using
this straight way. I'm asking again because I prefer not to upgrade the
firmware if this means I have to re-do all the steps that make my 770 work
like it is now. It's not too much stuff (yes, a fraction, compared to what
some of you there have on your 770), but time is precious and I hope
(vain?) there is some better solution for upgrading without pain: the
release of a new firmware for a device usually is a full
happyness-trigger, but if I think to what this currently implies it risks
to become a no-no-please! ^__^;;
If still I'm not clear, here it is my question re-explained in a more
developer-friendly way (I hope line-breaks will not make this unreadable):
////////////////////////////////////
// This is the "normal" approach: //
////////////////////////////////////
stuff = [collection of files and dirs that I can find via ssh]
770_before_flash = [%stuff% in my 770 before flash]
770_after_flash = [%stuff% in my 770 after flash]
hard_work = [on %770_after_flash%: reinstallation of all the packages, set
up of all the settings, configuration of all the configs, direct copy of
all the non-packaged apps, creation of all the symlinks, etc. (put here
whatever has been written on 770 internal memory after last reflash)]
770_after_hard_work = [%stuff% in %770_after_flash% after %hard_work%]
if (%770_after_hard_work% WORKS_LIKE_OR_BETTER_THAN %770_before_flash%)
TIRED_BUT_HAPPY
else DOH
////////////////////////////////////////////////////////////
// This is my question: will the following approach work? //
////////////////////////////////////////////////////////////
stuff = [collection of files and dirs that I can find via ssh]
flash_stuff = [collection of files and dirs that flash would touch]
ghost_stuff = [collection of files and dirs that we need not to backup
because they are just there as linux works (proc, lost+found, ...)]
good_stuff = [collection of files and dirs that make my 770 unique, my
favourite apps, settings, etc.]
if (%flash_stuff% + %ghost_stuff% + %good_stuff% != %stuff%)
PLEASE_SUGGEST_WHATEVER_ELSE
770_before_flash = [%stuff% in my 770 before flash]
770_after_flash = [%stuff% in my 770 after flash]
not_so_hard_work = [on %770_after_flash%: install xterm and openssh, copy
and overwrite the previously backup'd %good_stuff% of %770_before_flash%]
770_after_not_so_hard_work = [%stuff% in %770_after_flash% after
%not_so_hard_work%]
if %770_after_not_so_hard_work% WORKS_LIKE_OR_BETTER_THAN
%770_before_flash% then NOT_SO_TIRED_AND_HAPPY
else DOH
///////////////////////////////////////////////
I hope that's clear enough now. Let me know if not, I'll try something
else.
--
Antonio
_______________________________________________
maemo-developers mailing list
[email protected]
https://maemo.org/mailman/listinfo/maemo-developers
