On Fri, Jul 30, 1999 at 03:01:46PM +0200, Santiago Vila wrote: > 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. You're right, we do have to switch. Not all at once. > > 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). I don't see why. We have to support both (since any third party program following the FHS/LSB specs will use /var/mail) and we can support it in a matter of ... however long it takes to build/upload a new base-files and to have dinstall run. Regardless of when the policy takes effect, base-files needs to be updated to create the thing as necessary right now because we've got packages using it right now in Debian and there are those third party things to worry about too. > > > 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. This is very easy to do, and I suspect there's a lintian test for it too. I don't think policy should say that packages for potato may use hardcoded infodirs but anything after potato may not. Instead policy should say not to use hardcoded infodir options and if it turns out that it's okay to do for potato because of the transition, well, we don't have to worry about anything that does. Of course I don't know about the install-info thing. If RIGHT NOW packages can't do that then those packages must be fixed before release, not because of FHS migration, but because they will be broken otherwise. What I am objecting to is wording in policy to the effect that we should do something, followed by "don't do this for potato". Especially if it doesn't really matter if it's done for potato or not. > > [...] > > 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". Um, so .... upload a base-files that does this now and let it get installed into a few mirrors... If the dselect methods cannot handle this, they are broken. apt can handle it and is AFAIK the default with potato now that apt has a working cdrom method... > > 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? That's the point. The uploads are not required because we have determined ahead of time that FHS compliance is not critical at this point in time, though it is now officially policy and we have committed to start moving things to FHS locations. Which was good since people had already started doing this. > > 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. heh That explains that. I do believe every package uploaded now that is not simply a NMU or similar should in fact be FHS compliant. I think it is in the best interests of the users of my packages that my packages are as close to compliant with current policy as possible. So my packages are all uploaded with policy 3.0.1 currently. They also use debhelper v2, but that's more because I prefer the debhelper v2 way of doing things over the debhelper v1 way, it's more logical (I hate debian/tmp!) and since I track changes to debhelper closely I can easily keep up. However, that we don't want 3000 packages reuploaded right now just to change a few file locations is a given. And if packages have not converted to even partial FHS compliance yet (some people are holding back because of the /usr/doc issue for example) this is okay---for now. I agree we cannot indiscriminantly allow developers to implement policy or not as they choose, however we have agreed that immediate implementation of FHS standards right now is not yet a smooth operation. We have issues to deal with still regarding things like /var/mail, /usr/doc, and the FHS in policy now mandates /var/state which we know we should not use now. I would not object to notice in the policy that says for the moment where the FHS says /var/state we should read /var/lib and give rationale that this will be changed in FHS 2.1 which isn't released yet. Nobody is claiming we don't have to upgrade packages to FHS standards, however we have come to a consensus agreement that we don't have to do it before potato's release---except where necessary to support it of course. This means manpages and info docs need to be able to be in FHS locations, that we need to figure out what to do with the /usr/share/doc transition mess, and ... that's right, /var/mail will need to exist. -- 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 -------------------------------------------------------------------------- We the people of the Debian GNU/Linux distribution, in order to form a more perfect operating system, establish quality, insure marketplace diversity, provide for the common needs of computer users, promote security and privacy, overthrow monopolistic forces in the computer software industry, and secure the blessings of liberty to ourselves and our posterity, do ordain and establish this Constitution for the Debian GNU/Linux System.
Attachment:
pgpM2iHfrSqVA.pgp
Description: PGP signature