Am 15.10.2015 um 20:17 schrieb kp kirchdoerfer: > Hi Erich; > > Am Donnerstag, 15. Oktober 2015, 19:16:19 schrieb Erich Titl: >> Hi KP >> >> Am 15.10.2015 um 18:41 schrieb kp kirchdoerfer: >>> Hi Erich; >> >> .. >> >>> No; we only need the new package with the AC1 and the AC', which is in >>> configdb.lrp. >>> If you call apkg -u it will detect the changed file and it will offer you >>> to either Keep your version, Show differences, Edit a merge file or to go >>> with the new version. >> >> How can you merge if you don't have a difference > >>> I've checked that it even works, if you replace the original package with >>> the new version on /mnt. >> >> Yes, that works and it corresponds to >> >> - AC, AC1 and AC' are available, because >> from AC and AC' we can calculate D and apply it to AC1 > > In my tests D was calculated from AC1 and AC'. > Have you tested or did I something wrong when testing?
Yes, but this is not the changes the user made between AC and AC' The changes between AC1 and AC' are not D. > >> In my previous mail there was a typo in the condition above >> >>> Pls test. >>> >>> So what upgrade can do is to copy the package to /mnt and run apkg -u >>> afterwards from /mnt. If there are changes, the user can decide how to >>> proceed. >> >> This was the first test I did and I did not like it. It is noisy like >> hell. > > I'm running apkg -u very often and find it very convenient :) Most of the time it is and often AC == AC1, but that is not a safe assumption, as could be seen in the ez-ipupd case. Applying apkg -u to ez-ipupd.lrp would have led to something different. The correct sequence is to first calculate D and apply it to AC1. I am about to test this in upgrade. The only problem I see is the existence of local.lrp, which may contain just about anything, > >> And most importantly (at least to me) is _the user should not need >> to intervene_. This is because the average user has either forgotten the >> changes or applied them using a web interface of some sort. >> >> For example, if you use webconf to configure /etc/network/interfaces >> then the generated file will look a lot different from the one included >> in the distribution. The user may never have seen the original, how >> could he make an intelligent choice? > > In that case webconf has to be fixed IMHO. Webconf creates a very clean interface file. This is normal because it is machine generated and machines tend to do repetitive tasks better than hman beings. The original interface file is is a pretty crufty hand maintained file. If anything, then the initial interface file needs to be cleaned. But I don't believe this is necessary, as it is possible to correctly calculate the difference D. > >> Blindly just use the old configuration has it's problems, as seen >> before, even calculating the difference and applying it to the new >> config file may be error prone, but probably a lot safer than human >> intervention. >> >>> There has been introduced a safety feature, that every upgrade needs a >>> response (y/n) , even it doesn't touch any config etc..., but if changes >>> in the config are detected, you'll be offered with the menu to deal with >>> the changes. >> I messed around with apkg -u and looked at the implementation of >> apkg.merge and apkg.mergefile. These two scripts do nothing more than >> what 'diff -r' and 'patch' would do, probably just a lot slower. >> >> I would like to enable these two applets in busybox and I have done so >> in my local branch. Tests are encouraging. It could make the scripts a >> lot easier and more consistent than an implementation in bash. Any >> objections to enhance busybox? > > Ok; this is an IMHO a somewhat different/additional issue. I believe those are the tools for a solution. > You may either merge maint into next or pu (proposed updates) and add your > changes there so we can test. > Or you make a new (remote) branch with your changes so we can test. Sounds reasonable, I branched of 5.2 but can easily rebase it to maint. cheers ET ------------------------------------------------------------------------------ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
