Bug#207132: debian-policy is missing gcc transition plans
On Mon, Aug 25, 2003 at 12:26:16PM +0200, Josip Rodin wrote: http://people.debian.org/~rmurray/c++transition.html Ps: you might want to consider retiring the libc6 transition document. I'd rather if we dropped all such transitional issues from the Policy manual. They're just bother and don't really have to be here to be mandated by the project (examples abound -- libc6-migration, fhs migration, C++ 3 transition...). The technical committee can make a statement and be done with it. I'd rather we stopped looking at policy as mandating things. There are three things policy's trying to do at the moment: 1) specify technical standards, like version formats and package names 2) specify packaging and coding best practices 3) specify release requirements All these things are necessary if we want to maintain Debian as a highly integrated system -- people don't come to the project with the same expectations and experience, and we don't want to inflict the same mistakes on our users in perpetuity as new developers come along. http://people.debian.org/~ajt/sarge_rc_policy.txt is a good start at separating out (3), and I'm happy for the release team to continue maintaining that, even though it obviously is a little redundant wrt policy. (1) is easy to separate out -- there's only a couple of sections that specify APIs and formats rather than implications, mostly from the old packaging manual. That leaves (2) though, which really includes things like transition documents, and subproject policies, and most of the current debian-policy document. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgp8ZZlt10wZC.pgp Description: PGP signature
Re: Bug#207132: debian-policy is missing gcc transition plans
On Tue, 26 Aug 2003 02:44:00 +1000, Anthony Towns aj@azure.humbug.org.au said: I'd rather we stopped looking at policy as mandating things. There are three things policy's trying to do at the moment: 1) specify technical standards, like version formats and package names 2) specify packaging and coding best practices 3) specify release requirements Interesting. However, I find my vision of policy differs from yours, in some details, or perhaps in subtle interpretations. All these things are necessary if we want to maintain Debian as a highly integrated system -- people don't come to the project with the same expectations and experience, and we don't want to inflict the same mistakes on our users in perpetuity as new developers come along. http://people.debian.org/~ajt/sarge_rc_policy.txt is a good start at separating out (3), and I'm happy for the release team to continue maintaining that, even though it obviously is a little redundant wrt policy. (1) is easy to separate out -- there's only a couple of sections that specify APIs and formats rather than implications, mostly from the old packaging manual. That leaves (2) though, which really includes things like transition documents, and subproject policies, and most of the current debian-policy document. I see the primary task that the Debian project does is integration of software from diverse sources, and creating a uniform, integrated, operating system whose parts dovetail into each other, and work with each other, to create utility that exceeds the sum of the utility of each part. In my view, policy is supposed to represent the minimum set of rules that packages follow to allow the parts to dovetail together. The developers reference is the best repository of best practices -- common techniques that over time have been discovered to be desirable to adopt. Now, policy may currently be bloated, given its history, and does indeed contain best practices kind of material, but by and large, the goal is to pare it down to a ruleset _required_ for packages to interact and integrate tightly together. I, however, agree that policy is not a stick to beat developers on the head with, which is another way of stating what you said. manoj -- A crow perched himself on a telephone wire. He was going to make a long-distance caw. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#207132: debian-policy is missing gcc transition plans
On Tue, Aug 26, 2003 at 12:50:53AM -0500, Manoj Srivastava wrote: In my view, policy is supposed to represent the minimum set of rules that packages follow to allow the parts to dovetail together. I don't think that makes sense -- getting packages to dovetail together isn't something that can be achieved once and forever more; once we've got libraries and file hierarchies making sense and fitting together, we're not going to stop, we're going to start working on getting documentation put together in more consistent fashions, or stop Gnome from spewing assertions to xterms, or any number of other things. But doing any of that requires a document that's willing to cover all the things we're trying to achieve. Having many documents doesn't work, because packagers coming to Debian need to be able to find *everything* that affects them; having stuff undocumented doesn't work because otherwise not only won't new people know it, but those of us who decided what we'd do are liable to forget. The developers reference is the best repository of best practices -- common techniques that over time have been discovered to be desirable to adopt. No, it's not. The developer's reference is about procedures; debian policy is about packaging. And this is utterly appropriate; working out what to do (packaging policy), and how to do (uploading policy) are fundamentally different things. Procedures, like when to upload NMUs or the use of DELAYED queues, change by dictate and mood; technical policy whether you consider that best practices change only when new problems are noticed, or when new procedures become possible. Moving these things into other documents is a *mistake* -- it was a mistake when we did it to the packaging manual, one which continues to make policy confusing and difficult to follow, and it's a mistake to extend chapter six of the developers reference. [...] but by and large, the goal is to pare it down to a ruleset _required_ for packages to interact and integrate tightly together. What, exactly, do you think this means? It's not required in the sense that the package won't be allowed in Debian, or in a Debian stable release; that's http://people.debian.org/~ajt/sarge_rc_policy.txt. It's not required in the sense that the packages won't work at all, or even that it won't work for the majority of people; that would be even shorter than the sarge_rc_policy. I, however, agree that policy is not a stick to beat developers on the head with, which is another way of stating what you said. The Axiom of Choice is obviously true; the Well Ordering Principle is obviously false; and who can tell about Zorn's Lemma? (You did just disagree with me, then restate my comment and agree with it, right?) If you're not going to beat people on the head with policy, the only merit it has *at all* is as a compendium of well thought out advice to package maintainers about how to do their work. That is the *precise* definition of best practices documents. By contrast, sarge_rc_policy is a list of requirements, and is something to beat people over the head with. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpRzo5ld1LpH.pgp Description: PGP signature
Bug#207132: debian-policy is missing gcc transition plans
On Tue, Aug 26, 2003 at 02:44:00AM +1000, Anthony Towns wrote: I'd rather if we dropped all such transitional issues from the Policy manual. They're just bother and don't really have to be here to be mandated by the project (examples abound -- libc6-migration, fhs migration, C++ 3 transition...). The technical committee can make a statement and be done with it. I'd rather we stopped looking at policy as mandating things. There are three things policy's trying to do at the moment: 1) specify technical standards, like version formats and package names 2) specify packaging and coding best practices 3) specify release requirements I agree. However, the language used in the Policy Manual, and the organization of the manual itself (or lack thereof) is not necessarily appropriate for all of these issues. The document is right now used to mandate things, and obviously this creates problems when some things shouldn't be handled in that manner. I filed several bugs about it, not all of which are resolved yet... -- 2. That which causes joy or happiness.
Re: what is policy about?
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony http://people.debian.org/~ajt/sarge_rc_policy.txt is a Anthony good start at separating out (3), and I'm happy for the Anthony release team to continue maintaining that, even though it Anthony obviously is a little redundant wrt policy. I think I can see the point that Manoj is trying to make' but I can also see your point. It seems reasonable for the release team to maintain 3 provided that the intent is to eventually make the best practices in policy be release requirements. I'd see it as a problem if there were some best practice in policy that was implemented by a good fraction of the packages but the release team were not willing to accept that practice as a release requirement. I would not see it as a problem if the release team didn't want to make something a release requirement because doing so would be too hard to check, would remove too many packages, etc. I think I might also see it as a problem if the release team made some release requirement which conflicted with policy or for which there was not a consensus in favor of in the debian-policy community. I'm not sure though; I suspect I'd have to see some examples before I knew what I thought. What I'm trying to say seems to boil down to it's important that release requirements and best practices are relatively closely coordinated. I also think that the release team probably shouldn't be doing much inventing of requirements, but rather should be selecting from requirements proposed through policy and other channels for those that are consistent with the practical requirements of a release. --Sam
Wrong handling of empty strings in version numbers
Hi all, I think the handling of empty strings in version numbers is wrong (tested with dpkg 1.10.10). I experienced with two packages pkg_1.1beta3-1_i386.deb and pkg_1.1-1_i386.deb. It seems that 1.1beta3-1 is newer than version 1.1-1. Is this true? OK, let's analyze Debian Policy 3.6.1.0, section 5.6.11: * first 1.1 is compared with 1.1, they are equal, so the test continues * now is compared with beta3 (is this correct, or is - compared with beta3-?) an empty string ... counts as zero, so 0 is compared with beta3, because of letters sort earlier than all the non-letters we obtain 1.1beta3-1 1.1-1 ! Even if zero is considered to be the first ascii character \0, letters sort earlier leads to 1.1beta3-1 1.1-1 Am I wrong? Jens
Minor typo correction for Debian policy
Hello, Here is a very small diff fixing a typo against current CVS. --- debian-policy.sgml.orig Tue Aug 26 21:44:10 2003 +++ debian-policy.sgml Tue Aug 26 21:44:28 2003 @@ -7207,7 +7207,7 @@ string/em in some place, the following format should be used: vararch/var-varos/varfootnote The following architectures and operating systems are - currently recognised by prgndpkg-archictecture/prgn. + currently recognised by prgndpkg-architecture/prgn. The architecture, ttvararch/var/tt, is one of the following: ttalpha/tt, ttarm/tt, tthppa/tt, tti386/tt, ttia64/tt, Fred PS: Please CC me on replies
Bug#207132: debian-policy is missing gcc transition plans
On Tue, Aug 26, 2003 at 12:34:30PM +0200, Josip Rodin wrote: On Tue, Aug 26, 2003 at 02:44:00AM +1000, Anthony Towns wrote: I'd rather we stopped looking at policy as mandating things. There are three things policy's trying to do at the moment: 1) specify technical standards, like version formats and package names 2) specify packaging and coding best practices 3) specify release requirements I agree. However, the language used in the Policy Manual, and the organization of the manual itself (or lack thereof) is not necessarily appropriate for all of these issues. The document is right now used to mandate things, and obviously this creates problems when some things shouldn't be handled in that manner. I filed several bugs about it, not all of which are resolved yet... For whatever it's worth... As the remaining Policy editor -- though I admit I have been badly itinerant for the past several months -- I guess I should weigh in. I feel basically about policy as I expressed in the logs of bug #97671[1]. In my opinion the current dispute is basically a re-hash of the meta-discussions that cropped up while that bug took a trip to the Technical Committee. In my opinion, the role of the Policy Manual is: 1) Yes, to specify technical standards, like version formats and package names. 2) Possibly to specify packaging and coding best practices. These should *either* be in the Policy Manual appendices, or in a separate document. 3) *NOT* to specify release requirements. That should be a document under the control of the Release Manager DPL delegate, and of course that responsibility can be shared with whomever he sees fit (as mutually agreed upon). [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=97671 (scroll down about 25% and start reading). -- G. Branden Robinson| Convictions are more dangerous Debian GNU/Linux | enemies of truth than lies. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | pgpq7Sfb4n3wW.pgp Description: PGP signature
Fw: Debian-policy copy any DVD to a standart CD at home dIrDQnF
Title: uaJlCpI Hello, Debian-policy! wmxZGBI Freddy vs. Jason, Frontier Ye XLr stars battleigtUt The American student Wj
