Re: /var/lib, /var/mail
On Fri, 30 Jul 1999, Joseph Carter wrote:
> On Fri, Jul 30, 1999 at 01:09:22PM +0200, Santiago Vila wrote:
*> > > > 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.
>
> Not if my packages comply with an older version of policy and do not claim
> to comply with the new version. [...]
No. All packages have to comply with policy. I will quote it:
1.1 Scope
This manual describes the policy requirements for the Debian GNU/Linux
distribution.
I think the interesting word here is *requirement*. The way I read this,
it means it is *required* that packages behave according to policy.
I *never* talked about severity levels of bugs. You say FHS is not
release-critical for potato, and I agree, but this does *not* mean that we
don't have to switch to FHS.
> > 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.
>
> Then /var/mail is already policy and anything not using it should have
> bugs filed already. [...]
Yes, /var/mail is already policy.
But we should probably modify policy so that we don't follow /var/mail
yet, as an exception (I think it was Ian Jackson who started this
thread).
> [...]
> > If you mean there should not be mass bug reports regarding FHS yet, I
> > agree, but that's all.
>
> I mean that policy should simply state that policy should state the
> desired behavior. It should not be tied to releases and we shouldn't go
> about adding things to policy for specific versions of Debian.
Well, I disagree. Sometimes we have to do that. Think about the info
transition for example. We absolutely need to be sure that no package
is using install-info's --infodir option in a hardcoded fashion, before we
decide to move the index `dir' file to /usr/share/info.
> [...]
> Given that your entire objection to this proposal is that you don't want
> to see anybody implement it YET for some reason either I'm incapible of
> understanding or you're not explaining, I don't see the problem. [...]
I *did* explain: Lots of *Pre-Dependencies* on base-files. I think this is
bad, becuse upgrading without apt will make the upgrade to be *painful*.
"Pre-Dependency problem, foo not unpacked because it pre-depends on
base-files >= bar, base-files >= bar is not installed yet".
> [...]
> > I have to agree with Antti-Juhani's idea, that a policy which is not to be
> > followed is not a good idea.
>
> All packages are not supposed to be reuploaded for FHS compliance, yet
> this is policy.
Mmm, I don't understand... How do you plan to make your packages
FHS-compliant without making any uploads?
> Why didn't you make that objection before the FHS went in?
If you mean: "Why didn't you objected to the switch from FSSTND to FHS
if you wanted to make an exception for /var/mail?", the answer is very
simple:
My mistake.
--
"4236c7ce4f3eac9ab28186f9a9634cf8" (a truly random sig)
Reply to: