Hi KP > I also _believe_ , that integration of apkg -u into the upgrade script will > be > easier to accomplish the then smaller changes and more helpful, than reinvent > apkg and configdb.
I have been thinking hard about this and I believe you are wrong in this aspect. Let me state why I think this is so - we have a package A of version 1.0 which we just call A - we have a config file AC belonging to package A , call this AC - we have an installed package A with a modified config file AC, call this AC' - we can detect the difference between AC and AC', lets call this D - we have a package A of version 1.1, lets call this A1 - we have a config file AC belonging to package A1, lets call this AC1 - let us assume that AC <> AC1 - we want an installed package A1 with the adjusted config file AC1' therefore we need a transformation from AC' to AC1' - there is no direct transformation from AC' to AC1' - we can build AC1' by applying D to AC1 Right now we do not save D, but we save AC' If we replace AC by AC1 (by replacing the corresponding package A by A1) then we lose the capability to generate the difference D and as a consequence we loose the transformation from AC1 to AC1' This leads me to the conclussion that the transformation of AC' to AC1' cannot only work if either - D is saved, because then we can apply D to AC1 - AC, AC1 and AC1' are available, because then we can calculate D So a tool like apkg -u cannot work unless it is applied from a location different from the original boot location, because once the package A has been overwritten by A1 the reference to AC is lost. Is there a description how apkg -u is to be used? cheers ET ------------------------------------------------------------------------------ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
