Hi Frank! On Don, 06 Okt 2005, Frank Küster wrote: > To me it seems there are two issues here. The first is that our dialog > gives the impression that we do not simply *add* permissions, but
Ok, this is only about the spelling of the managedlsr template, I guess. This can be fixed easily. > The second is "local changes must be preserved". This means: > > - in noninteractive mode, we should not make any changes upon upgrade, > only upon first installation (check for the second argument to the > config script). > > - in interactive mode, or when called by dpkg-reconfigure (no way to > discriminate these two situations), we must be careful. > > a) If all possibly managed ls-R files have the same permissions and > group ownership, we can simply ask our question and add or remove > permissions, and change groupship according to the answer. If the > owning group is not "users", we should change the default to the > other name. > > b) If the permissions are different, but look just as we would > generate them - that is: all ls-R files that are 664 have the same > owning group, all ls-R files that are 644 also belong to one group > (which might be the same or different than for the 664 files) - > then it is also easy to handle this: We simply adjust our settings > according to the existing situation, ask the question and act > accordingly. > > c) However, if ls-R files of the same permission kind have different > group ownership, or if there are ls-R files that are neither 664 > nor 644, we are in trouble. I read through your proposal and have a hard time to understand it. I wrote a bit of PseudoCode what should be done. What do you think about this: ------------------------------------------------------------------- config file operation ===================== fresh install: any mode -> use our defaults upgrade: non-interactive mode -> do nothing *at all*, not even ask anything interactive mode: ask for which files should be managed by debconf store in OldManagedLsrFiles files which have already been managed and are still managed store in ManagedLsrFiles all the files managed by debconf read in current permissions and owners of OldManagedLsrFiles if (allEqualGroup(OldManagedLsrFiles) and allEqualPermission(OldManagedLsrFiles)) # set the DebConf Values to the common group/permissions # doesn't hurt if the permissions have been the same anyway # this is case (a) and (b) together set DebConfGroup to allEqualGroup set DebConfPermissions to allEqualPermission else # there is an old file which actually was modified from the # debconf setting. We have to find it and ask the user what # should happen with it! This is case (c) I would say for lsr in OldManagedLsrFiles do if CurrentPermissionsGroup(lsr) != DebConfPermissionsGroup(lsr) then warn the user that this file was managed originally, and should be managed further on, but has inconsistent permission/group Ask wether it should be fixed to debconf or left alone if User selects fixed to DebConf then do nothing (ie leave lsr file in ManagedLsrFiles) modification of permissions will be done in the postinst script else change ManagedLsrFiles to not include lsr fi fi done fi ask all the other questions about permissions/group postinst operation ================== fresh install: carry out the fix permissions/owner according to DebConf (or leave alone if nothing is selected) upgrade: noninteractive mode: do not touch any ls-R file, do nothing interactive mode: set permissions/group according to DebConf ------------------------------------------------------------------- > press you to anything). We would have one question for tha a and b > cases, and an informational message in the c case. This would give one additional question. The one about what you want to do with the changed lsR file. > >> Furthermore, LOCALTEXMF's ls-R file is only managed if it resides in > > After reading Section 9.1.2 of the Policy, I think that we may not > create files below /usr/local at all (only directories). Therefore we > should remove the link from the package, and remove localtexmf from the > debconf template. Ok, this makes life easier. Best wishes Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining <preining AT logic DOT at> Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- GIPPING (participial vb.) The fish-like opening and closing of the jaws seen amongst people who have recently been to the dentist and are puzzled as to whether their teeth have been put back the right way up. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]