Re: Bug#528021: maintainer scripts put files in /usr/local/ (policy 9.1.2)
On Mon, May 11 2009, Holger Levsen wrote:
> Hi Bill,
>
> On Montag, 11. Mai 2009, Bill Allombert wrote:
>> But policy allows creating directory like /usr/local/share/texmf in the
>> postinst.
> [...]
>> It seems to me that mktexlsr could honour policy if
>> /usr/local/share/texmf/ls-R was only created when it would be not empty
>> (i.e. the user installed files in /usr/local/share/texmf/)
>
> Please read the whole bug.
I have read the whole bug, and I still do not know what your
response would be here.
So, the way I see it is:
a) Users may provide local TeX files in /usr/local, and mktexlsr will
know about them, and index them in /usr/local/share/texmf. The
package is perfectly fine in creating /usr/local/share/texmf, as
allowed by policy.
b) The ls-R file of /usr/local/share/texmf is NOT in /var/lib/texmf,
but lives in /usr/local. This is fine too.
c) If the end user allows mktexlsr to run, say, in cron, than the LS-R
files has been created by the user's agent, which is tgheir
prerogative.
The problem, apparently, is not that /usr/local/share/texmf is
created, but that mktexlsr is run without a directory list in the
postinst, and thus creates the ls-r file in /usr/local. With that one
issue fixed, there should be no policy infraction.
And this certainly does not look like a deficiency in
policy. Packages which support user supplied libraries and sources
should allow users to use that functionality easily; and thus the
whole policy dictum about creating dirs in /usr/local.
If you think I am mistaken, please point out what I am missing
explicitly, rather than vague references to reams of previous messages.
manoj
--
Parkinson's Fourth Law: The number of people in any working group tends
to increase regardless of the amount of work to be done.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: