Bug#332264: tex-common: permission-handling of ls-R files is one-way
Norbert Preining <preining@logic.at> wrote:
> But stop, well, isn't this the whole point of it???
>
> Asume someone managed xyz-ls-R with debconf.
> Then changes permissions/owner.
> Then realizes that he has to reconfigure tex-common.
> Then he calls dpkg-reconfigure -plow tex-common
> What should tex-common do? Change permission/owner?
>
> I would say no. I guess we need more discussion here.
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
*remove* as well. If we want to stick to only adding, at least we must
check them before and only offer the choice to add if there is anything
to add. Otherwise we should implement the removal.
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.
To me it seems as if this shouldn't be too hard to implement (although I
didn't even look at your first, now reverted change, and don't want to
press you to anything). We would have one question for tha a and b
cases, and an informational message in the c case.
>> Furthermore, LOCALTEXMF's ls-R file is only managed if it resides in
>> /var/lib/texmf. Since there was no such symlink in older versions, we
>> should either provide a transition (is fiddling with /usr/local allowed
>> in maintainer scripts?), or at least document it.
>
> This has to be discussed, too.
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.
What the others think?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: