[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

> [...]
> > 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

My mistake.

 "4236c7ce4f3eac9ab28186f9a9634cf8" (a truly random sig)

Reply to: