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. Unless of course there is some real important (perl) reasons to upgrade your packages RIGHT NOW (perl) to a new policy... (perl) It has already been said that for potato NO FHS COMPLIANCE ISSUES shall be release critical bugs. Which makes the purpose of your argument---that if we make /var/mail policy everything must use it for potato---a moot point entirely. > 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. Changing the policy to remove the conflict is not a problem and not implementing the a symlink or similar immediately will result in lost mail and other problems. In that case my proposal should be considered on the level of a report of a typo and the solution in the proposal of creating the symlinks must be done immediately to prevent people from losing mail. In both cases arguably discussion doesn't really matter and in the latter case because of the gravity of the problem (lost mail is inexcusable--ask Branden) the discussion should take place after the necessary problem has been fixed. FWIW, we already have programs that use /var/mail by default simply because glibc has /var/mail someplace and they read the default from libc... This was the case before policy 3.0.0, which was then a bug in glibc and those packages. No longer however. > 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. Instead we should simply provide the mechanism for packages to be able to comply with what is ALREADY policy (the FHS) and keep the backwards compatibility for packages that don't yet. And we should agree that for potato there's no need to upgrade everything to /var/mail and in fact it's even probably even a good idea not to upload new packages just to comply with use øf /var/mail today. > > 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*? Because FHS is policy *now*. Packages use /var/mail *now* (fortunately so far nothing which does has seriously hurt anybody..) > It's usually much easier to rely on something not being policy yet > than to rely on common sense. Harm in making it policy now and ignoring that packages don't do it yet (as we have already agreed to do) none Harm in NOT making it policy now and leaving packages broken because of /var/mail mail may be lost Harm in making finding out exactly which packages use delays, may miss /var/mail already and shouldn't and filing bugs and packages meaning waiting for them to get fixed or doing NMUs or whatever mail may be lost Are packages that use /var/mail now broken? yes. Do you know exactly which packages were compiled with glibc telling them to use /var/mail? I can guess it's not many because we haven't seen many reports of lost mail.. 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. Nor do I see the purpose in arguing about it if you plan to oppose any proposal which doesn't include a sentance to the effect of "Even though everything is all set for you to use /var/mail in potato and policy now says to use /var/mail, you're supposed to ignore that until after we release potato" I will oppose any such change to my proposal. Policy should not be tied to any particular Debian release. It should instead list what packages which comply with it should do. > 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. Correct. That and many packages already had transitioned anyway. > 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. You haven't given me a good reason why packages should not use /var/mail internally yet. As soon as an updated base-files is installed and can be referenced, packages should start using it if they update to FHS standards. Of course it's okay if they don't right now for the same reason it's okay if they don't use anything else the FHS requires 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. Why didn't you make that objection before the FHS went in? -- Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE -------------------------------------------------------------------------- <Kethryvis> Gruuk: UFies are above and beyond the human race :)
Attachment:
pgpvrkSMLlyAQ.pgp
Description: PGP signature