Re: [leaf-devel] git should not track conf/buildtool.conf globally
Hi. Use buildtool.local instead. 15.10.2015 00:38, Erich Titl пишет: > Hi Folks > > stupid question... > > How do you avoid the following > > mega@leafbuilder:~/leaf/devel/bering-uclibc$ git status > Auf Branch maint > Ihr Branch ist auf dem selben Stand wie 'origin/maint'. > > Änderungen, die nicht zum Commit vorgemerkt sind: >(benutzen Sie "git add ..." um die Änderungen zum Commit > vorzumerken) >(benutzen Sie "git checkout -- ..." um die Änderungen im > Arbeitsverzeichnis zu verwerfen) > > geändert: conf/buildtool.conf > > I just modified the packager name :-( > > 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
[leaf-devel] apkg -u, the deception?
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
Re: [leaf-devel] apkg -u, the deception?
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
Re: [leaf-devel] apkg -u, the deception?
Hi Erich; Am Donnerstag, 15. Oktober 2015, 08:27:56 schrieb Erich Titl: > 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. 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. I've checked that it even works, if you replace the original package with the new version on /mnt. 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. 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. > Is there a description how apkg -u is to be used? Only the source code... kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] apkg -u, the deception?
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 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. 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? 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? cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
