Hi Erich; Am Donnerstag, 15. Oktober 2015, 23:52:31 schrieb Erich Titl: > 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.
I think we don't need three-way diff. We are only interested by apkg -u in AC' and AC1. Why in a usual use case do you need the diff between AC and AC'? > >> 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. I believe this is a very special case, where the config mimic has been changed. > 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, Yes, this is our last resort for everything else - and totally unpredictable. > >> 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. The cruft will be part of nearly every config file not build webconf, which is IMHO the default as long as we don't update each and every package to webconf. What you call a mess is IMHO helpful, because it contains user created notes etc.. I document changes and reasons in the config file (like /etc/network/interfaces), and won't miss this feature. > >> 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. I haven't looked into your new branch - but first question first - do you just cleanup/speedup apkg, or do you make your changes to replace the current apkg -u mimic? kp > > 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 ------------------------------------------------------------------------------ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
