Bug#332264: tex-common: permission-handling of ls-R files is one-way

[Norbert Preining <preining@logic.at>]

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:preining@at43.tuwien.ac.at                             +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