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)
