Re: /var/lib, /var/mail
On Thu, 29 Jul 1999, Joseph Carter wrote:
> > > FHS issues should not be bugs in potato---next version maybe, but not
> > > potato, I agree.
> >
> > For this reason we have to be careful in the wording.
>
> No we don't. =p I have no intention of recompiling all of my packages
> for policy 3 before we release potato. Most people don't. (Most of mine
> have gotten recompiled because I've been lazy but that's beside the point)
Well, I think you mean that there is not a great hurry to convert
all your packages to FHS. That is up to you.
I think this issue is quite simple: Policy says packages have to be
FHS-compliant. So every package not following FHS violates policy.
A violation of policy is a bug.
Whether or not you will be able to fix all the bugs in your packages
(either of FHS-type or whatever) does not mean not being FHS-compliant
is not a bug. FHS has been made policy.
If you mean there should not be mass bug reports regarding FHS yet, I
agree, but that's all.
> I don't want to go and add cruft to the policy that says essentially "This
> is policy but you shouldn't go out and reupload all of your packages so
> they do things the new way just because there's a new policy."
Then why do you want to make it policy *now*?
It's usually much easier to rely on something not being policy yet
than to rely on common sense.
We made FHS to be policy because we wanted the FHS transition to start
*now*, even if we know it will not be finished by the time potato is
released.
If we don't want packages to refer to /var/mail internally yet, the best
thing to do is to forbid it by policy, not to allow it and then expect
common sense from the developers not to start the transition in potato.
I have to agree with Antti-Juhani's idea, that a policy which is not to be
followed is not a good idea.
Thanks.
--
"0fae5719186055232b7e0fc1a8d664f6" (a truly random sig)
Reply to: