Hi Phil, The idea sounds great. I tested it and I can get all parameters that are neccessary in my script. Parsing parameters looks more clean to me than the logfile.
So for simple operations this would be a good replacement! *But* If i am performing updates or also dist upgrades on my servers I would like to keep apt-actions as one big transaction (and checkin) instead of seperate dpkg ones. The reason behind is if something went wrong during an system-update I can investigate (via trac timeline and source browser) in exactly one changeset and see what files were changed. Also if no config changes appear for the specific package I can at least see an entry of the apt-action in my changelog, which is also without configuration changes, very informational. Otherwise I need to handle that via an empty commit, which I personally would like to avoid. Also I see revision number raising very fast especially when performing updates on more than one machine. What I could do is building something like a queue via the dpkg replacement and perform the checkin via the Postinstall hook. This way I can keep with the yes/no for the admin, performing the checkin. I need to think about that further... Cheers, Gunnar Philipp Marek wrote: > Hello Gunnar! > > I had another idea some days ago, and it came back to me now that you've > committed that. > > How about using the package names directly, instead of parsing the logfile? > > I'd suggest changing the apt configuration, but not to call something *after* > dpkg, but > *instead*: > # apt-config dump | grep dpkg > ... > Dir::Bin::dpkg "/usr/bin/dpkg"; > > Just call some shell script that commits /etc before and after the _real_ > dpkg run! > It could check whether the parent is apt, so that normal commandline use > wouldn't incur > the overhead. > > This would allow to directly use the package names that are given to dpkg; so > a "apt-get > dist-upgrade" would be split into several commits, one per dpkg run. > > How about that? > > > Regards, > > Phil > > ------------------------------------------------------ http://fsvs.tigris.org/ds/viewMessage.do?dsForumId=3923&dsMessageId=2444888 To unsubscribe from this discussion, e-mail: [[email protected]].
