> Hi, Hi.
My daughter is back home from the hospital, but I'm basically being a housewife (and responding to emergency calls from work) while my wife takes care of her. I hope to be back in the normal swing of things by next Monday. You can wait till then for me to prepare a ballot or do something to bypass me. [I'm sorry about the delay.] On Thu, Aug 19, 1999 at 01:35:38AM -0500, Manoj Srivastava wrote: > >> So how do we have major transitions like the one being > >> contemplated now? To wit: old policy said that packages follow the > >> FSSTND. At some point in the future, we are to follow the FHS. How > >> does one modify policy in such a way that would avoid your objection? "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: > Raul> Why not design the transition so that existing (FSSTND) > Raul> packages can be compliant with policy, but so that new packages > Raul> can also comply with FHS? On Mon, Aug 23, 1999 at 11:53:46AM -0500, Manoj Srivastava wrote: > Colour me confused. How does this help move the old packages > over? If the new packages are to comply with the FHS, and old > packages with the FSSTND, we are just prolonging the transition, and > we still need something like the symlinks proposal to handle end user > frustrations of having the docs and cop[yright files in two places, > and Joeys proposal to allow for aprtial upgrades to potato. > > Am I missing what you mean by ``new packages''? I meant newly prepared packages -- new package instances. Also, I wasn't recommending any details here -- just that nothing should break. > Raul> I'm aware that there's a dpkg bug which causes a problem with the > Raul> obvious solution for /usr/doc/, but that seems like not a good reason > Raul> to jump in with policy changes which declare every package buggy. > > One solution is to declare that packages conforming to > Standards version 3.X have to move to FHS (modulo exception > noted in the policy manual). Packages can still conform to 2.5.0.0 > and not be buggy. That doesn't solve the interface issue. There was email to the policy group before 3.0.0.0 was "ratified" which mentioned examples of debian packages which would break. > Indeed, that is not a satisfoactory solution, since now the > bug is ancient standards Version, as lintian helpfully points out. Among other things, yes. > Raul> Debian developers are pretty good about heading towards agreed on > Raul> goals, by the way... [Though with as many packages as we have change > Raul> cannot be fast.] > > In that case, unless the policy dictates the move, I think we > have prolonged the transition -- making it harder for us to conform > to the LSB, whenever that comes out, and would tend to mark Debian as > an old fashioned distribution behind the times (as usual). > > It is not as if one were proposing mass bug reports, or even > that conformance to standards version 3.0.0 was release critical in > any way. > > Quite frankly, looking at the age of some of the bug reports > on major packages, I fail to see what the big deal is about > having packages be buggy. (1) adding more bugs does not get rid of existing bugs. (2) constitutionally: creating bugs in packages which you're not the maintainer for exceeds the authority of the debian-policy maintainers. > Being constrained to only making policy changes that do not > make packages buggy is putting the policy amendment process in a > strait jacket that may well be detrimental to the project. The only strait jacket is that the technical committee is supposed to ratify such changes. [And once they've done so or refused to do so the developers can override.] So the strait jacket is us being slow. [And, once again, I apologize for being so slow.] -- Raul
