Bug#885698: What licenses should be included in /usr/share/common-licenses?
At 2023-09-10T21:47:36+0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Bill Allombert (2023-09-10 18:29:36) > > On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote: > > > Jonas Smedegaard writes: > > > >> Hmm, how about providing license-common package and that > > > >> depends on "license-common-list", and ISO image provides both, > > > >> then? It would be no regressions. > > > > > > I do wonder why we've never done this. Does anyone know? > > > common-licenses is in an essential package so it doesn't require a > > > dependency and is always present, and we've leaned on that in the > > > past in justifying not including those licenses in the binary > > > packages themselves, but I'm not sure why a package dependency > > > wouldn't be legally equivalent. We allow symlinking the > > > /usr/share/doc directory in some cases where there is a > > > dependency, so we don't strictly require every binary package have > > > a copyright file. > > > > Or we could generate DEBIAN/copyright from debian/copyright using data in > > license-common-list at build time. So maintainers would not need to manage > > the copying themselves. [...] > I have zero legal training so the only potential problem with this approach > that I was able to come up with is, that then the source package itself would > not anymore contain the license text ...why wouldn't it? Remember how a source package is defined: A DSC file, an upstream source archive (maybe more than one in exciting new source formats I haven't learned), and a compressed diff of Debian changes. Debian _source_ packages generally don't chop copyright notices and license texts out the upstream distributions, and should not do so unless those notices/texts are invalid or the material they cover has been removed. (Both of these do sometimes happen.) Even if one worries about theoretical liability due to the existence of separate files for .dsc, .tar.gz, and .diff.gz, then let us recall that (1) the DSC is minimal, containing metadata that may not rise to the threshold or originality required by copyright [in the U.S., anyway]; (2) the upstream archive has the notices and texts that the _original distributor_ put in it, and as a rule, if permission to distribute the work exists, it is not incumbent on redistributors to add notices/texts where the rightsholder themselves neglected to do so; and (3) the .diff.gz will not be in the business of removing notices/texts except as contemplated in the previous paragraph (correcting erroneous notices).[1] > and thus we would be shipping code covered by a license that states > that the code may only be distributed with the license text alongside > it without that text. I don't think that is a risk as long as people continue to follow packaging practices that Debian has applied with little objection from our upstreams for 25+ years.[2] > So while auto-generating this would probably create compliant binary > packages, it would leave the source package without the license text. I am unable to imagine the mechanism by which that would happen, given what Russ and Bill proposed. Regards, Branden [1] When repackaging, e.g., to remove non-free material, affected content is removed altogether even from the source. Nothing in copyright law can compel you to distribute copyright notices and texts that don't apply to work you're not distributing.[3] [2] I don't know of Debian _ever_ having had a problem, as in receiving a cease-and-desist letter or other threat of legal action with what one might term an "institutional" copyright holder. We've certainly had our share of nasty emails from cantankerous individual copyright holders, often who had their own perverse misreadings of licenses drafted by others (hello to the memory of Jörg Schilling). There also was once an upstream who stuck a Trojan horse into the source code to try to get Debian's users to stop using versions we distributed, but to go directly upstream instead. Nowadays, that seems quaint; you can today Trojan your machine much more conveniently with npm(1). [3] At the same time a few non-free FSF manuals under the GNU FDL declaim the GNU _GPL_ text to be an Invariant Section. Like most of the defects of the FDL, I think this is a pointless encumbrance; if you distribute GPL'ed software, a copy of its text must come along anyway. The only rationale I can imagine is to mandate, for printed copies of the manuals, the inclusion of the GPL's preachy preamble. But I digress. signature.asc Description: PGP signature
Re: Shouldn't shipping broken symlinks be against policy?
At 2018-11-13T17:02:49+, Ian Jackson wrote:
> G. Branden Robinson writes ("Shouldn't shipping broken symlinks be against
> policy?"):
> > Not reopening, but I have some questions for the Policy team.
> ...
> > I could have sworn you were incorrect, but sure enough, I read §10.5
> > carefully and grepped the rest of the policy manual and could find no
> > such prohibition.
>
> I don't think there is anything *inherently* wrong in shipping a
> broken symlink.
I almost do. :-D
> But if a broken symlink causes some kind of malfunction then that
> seems to be just a bug. Not every bug is a bug because it contravenes
> policy. Some bugs are just bugs :-).
>
> > Well, when a package ships a man page, I expect something more
> > illuminating to happen than:
> >
> > $ man rust-gdb
> > /usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling
> > symlink
> > No manual entry for rust-gdb
> > See 'man 7 undocumented' for help when manual pages are not available.
>
> I agree that this is untidy and undesirable. I don't see any good
> reason why one would want to do this rather than shipping the
> rust-gdb.1.gz symlink in the same package as the thing it points to.
>
> I guess the maintainer will also think this is a bug.
No; he closed it, and cited Policy's lack of a prohibition of shipping
broken symlinks in support of the present arrangement.
> Did anyone report it ?
That would be me.
--
Regards,
Branden
signature.asc
Description: PGP signature
Shouldn't shipping broken symlinks be against policy?
Not reopening, but I have some questions for the Policy team. At 2018-11-13T16:26:00+, Ximin Luo wrote: > Control: notfound -1 1.28.0+dfsg1-2 > > Closing, as far as I can tell it is not against Policy to ship a > broken symlink, I could have sworn you were incorrect, but sure enough, I read §10.5 carefully and grepped the rest of the policy manual and could find no such prohibition. It is certainly untidy. So I ask the Policy team--_shouldn't_ it be prohibited? > if it doesn't affect the functionality of the package. Well, when a package ships a man page, I expect something more illuminating to happen than: $ man rust-gdb /usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling symlink No manual entry for rust-gdb See 'man 7 undocumented' for help when manual pages are not available. > The man page is available in the rust-doc package which is already in > Suggests. In that case, isn't a better fix to put the symlink in that package, too? On my buster system, this is the only one of over 4,300 symlinks in /usr/share/man that is broken: $ find /usr/share/man -type l | wc -l; for F in $(find /usr/share/man \ -type l); do if ! test -f "$F"; then file "$F"; dpkg -S "$F"; fi; done 4938 /usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz rust-gdb: /usr/share/man/man1/rust-gdb.1.gz > X > > G. Branden Robinson: > > Package: rust-gdb > > Version: 1.28.0+dfsg1-2 > > Severity: normal > > File: /usr/share/man/man1/rust-gdb.1.gz > > > > $ dpkg -S /usr/share/man/man1/rust-gdb.1.gz > > rust-gdb: /usr/share/man/man1/rust-gdb.1.gz > > > > $ file /usr/share/man/man1/rust-gdb.1.gz > > /usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz [snip] Thanks for your time. Policy mavens, please CC me or the bug on replies; I don't subscribe to a billion lists like I did in the old days. Regards, Branden signature.asc Description: PGP signature
resignation from Debian Policy team
I hereby tender my resignation as a member of the Debian Policy team. It's no secret that I haven't contributed much to the Policy Manual in a while, but my decision is motivated by the fact that I don't want to be perceived as having the DPL's thumb on the scales when it comes to Debian Policy deliberations. Debian webmasters, Please update http://www.debian.org/intro/organization accordingly. -- G. Branden Robinson|Somewhere, there is a .sig so funny Debian GNU/Linux |that reading it will cause an [EMAIL PROTECTED] |aneurysm. This is not that .sig. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Fri, Nov 14, 2003 at 01:54:51PM +, Julian Gilbey wrote: In response to Branden's question (does debian/control already have to exist when the package is unpacked), I would suggest the following: Before debian/rules build* is run, one has to check the build-dependencies. So at this point, at least the source section of debian/control must exist. Acknowledged. I don't think there's anything wrong with requiring people who want to generate debian/control to make their build targets depend on debian/control. This doesn't make *unpacking* depend on the presence of debian/control. And since this field (whatever form it eventually takes) would exist in the source section of debian/control, and would not be needed until after the build-dependencies are checked, there should be no problem. And then again, we can always use debian/interfaces or debian/rules.targets or something similar instead I really like the debian/interfaces proposal. -- G. Branden Robinson|The errors of great men are Debian GNU/Linux |venerable because they are more [EMAIL PROTECTED] |fruitful than the truths of little http://people.debian.org/~branden/ |men. -- Friedrich Nietzsche signature.asc Description: Digital signature
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Fri, Nov 14, 2003 at 04:01:25AM -0600, Luca - De Whiskey's - De Vitis wrote: So you are going to implement this even if the discussion is not already closed. Of course you can implement it anyway, but it's unfair to ignore what Branden Robinson asked: Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Which is also of interest to me. You might have privately replyed, but in this case i'd like the answare to be sent here for logging too. *I* haven't gotten any private replies from Adam about this. None that weren't duplicates of mails to the -policy list, anyway. Grumble, grumble. -- G. Branden Robinson| You live and learn. Debian GNU/Linux | Or you don't live long. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Mon, Nov 10, 2003 at 11:26:24AM -0600, Adam Heath wrote: On Mon, 10 Nov 2003, Branden Robinson wrote: Uh, what if I want to put the following at the very top of my debian/control file? # $Id$ I was given to understand that dpkg 1.10.15 or so would be just fine with it, whereas dpkg 1.9.21 or so would vomit all over it. Placing comments in the leading paragraph may cause problems with older versions. However, for buildds, the build-depends will already be installed by the time your package is unpacked, so in practice, I doubt this is of much concern. Is there a reason we need to preserve the (presumably existing) requirement that debian/control exist in the .tar.gz or diff.gz? What is debian/control used for during package unpack? -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Sat, Nov 08, 2003 at 06:24:09PM -0600, Adam Heath wrote: On Fri, 7 Nov 2003, Branden Robinson wrote: On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote: Joy proposed to put such information in debian/control instead. The idea of a new file was to ease parsing, but since it is read by dpkg-buildpackage it should be OK. This prevents people from using tricks like debian/control.in. debian/control *must* exist when the source package is unpacked. Period. Whether it is overwritten later, is a separate matter. Uh, what if I want to put the following at the very top of my debian/control file? # $Id$ I was given to understand that dpkg 1.10.15 or so would be just fine with it, whereas dpkg 1.9.21 or so would vomit all over it. -- G. Branden Robinson| There's something wrong if you're Debian GNU/Linux | always right. [EMAIL PROTECTED] | -- Glasow's Law http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote: Joy proposed to put such information in debian/control instead. The idea of a new file was to ease parsing, but since it is read by dpkg-buildpackage it should be OK. This prevents people from using tricks like debian/control.in. debian/rules.in is almost impossible, but debian/control can be generated by debian/rules. Also, having to parse debian/control to determine what format debian/control might be in is a bad idea. -- G. Branden Robinson| Convictions are more dangerous Debian GNU/Linux | enemies of truth than lies. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Wed, Nov 05, 2003 at 02:35:44PM -0600, Luca - De Whiskey's - De Vitis wrote: So, why not a mix of these two? why don't we attach the concept of interface to the entire source package? debian/interface could be a file in which we describe the interface implemented by each component (object) of the source package. $ cat debian/interface rules: rules-interface1, rules-interface2, ... control: control-interface1, control-interface1, ... I don't have a problem with this at all. -- G. Branden Robinson| The software said it required Debian GNU/Linux | Windows 3.1 or better, so I [EMAIL PROTECTED] | installed Linux. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#218893: Alternative proposal: debian/format
On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote: Choose one: The first is to add a debian/rules.version with meaning: debian/rules.version is present and is 1\n: build-arch and build-indep are implemented The second is to add a debian/rules.targets with the list of available optional targets. First solution is easier to implement. Second one scale better but does not allow to revoke the meaning of a target. If you are going to second this proposal, please state if you prefer debian/rules.version or debian/rules.targets. I like the general idea, but I prefer neither name. Why are we attaching a versioning concept only to the rules file? I think we should attach versioning to the entire layout of the unpacked source package. This gives us the flexibility to make other kinds of changes without cluttering debian/ with still more files. Consider a file debian/format: $ cat debian/format rules: 1 control: 2 The above tells dpkg that the package in question is using version 1 of the debian/rules specification, and version 2 of the debian/control specification. (We could retroactively define version 2 of debian/control as one that permits comments, for which dpkg recently added support.) The debian/format file can be extended arbitrarily to suit our needs. We could change the format of a debian/changelog file with this technique as well, if needed. Of course, version 1 is assumed for everything in the absence of a debian/format file. Comments? -- G. Branden Robinson|Lowery's Law: Debian GNU/Linux |If it jams -- force it. If it [EMAIL PROTECTED] |breaks, it needed replacing anyway. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#218530: Suboptimal conditional rune for initscripts
On Sat, Nov 01, 2003 at 04:55:36PM +, Ian Jackson wrote: Branden Robinson writes (Re: Bug#218530: Suboptimal conditional rune for initscripts): Ah, I see the reason: ... [127] [EMAIL PROTECTED]:~ % ash $ type ls ls is /bin/ls But you don't, because it has a nonzero exit status if the command is not found - and foundness is the only thing the maintscript is interested in. Ah, right. Well, then, type and which seem to be equivalent. which seems far more intiutitive to me, but then I grew up using TCSH and am accustomed to most shells having it as a built in. -- G. Branden Robinson| Never attribute to malice that Debian GNU/Linux | which can be adequately explained [EMAIL PROTECTED] | by stupidity. http://people.debian.org/~branden/ | -- Hanlon's Razor signature.asc Description: Digital signature
Re: Package which uses jam (instead make)
On Wed, Oct 29, 2003 at 04:04:35AM +0100, Henning Makholm wrote: Scripsit Marcelo E. Magallon [EMAIL PROTECTED] excutable makefile, ok, this is the point of contempt. If we're actually regarding each other's views with contempt, then there's not much point in continuing the discussion, I think. Oh, come on. It's obvious from context that he meant contention, and misspoke. Not all of us on these lists are native English speakers, but that doesn't excuse deliberate misconstrual of other people's words. -- G. Branden Robinson| You live and learn. Debian GNU/Linux | Or you don't live long. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Package which uses jam (instead make)
On Wed, Oct 22, 2003 at 01:37:36AM +0200, Josip Rodin wrote: On Tue, Oct 21, 2003 at 05:03:53PM -0500, Manoj Srivastava wrote: If you do not stick to the documented interfaces, you lose the ability in my eyes to express outrage when the interfaces you use change. Except one important difference -- in this case, NOTHING CHANGES in the interface if the policy proposal is accepted. We just disallow some usage that has been explicitley stated to work. No. How did you come to that conclusion? This is another time you're giving the impression of don't take away my makefile rules files!. Well, maybe there's some Grinch out there who wants to steal them away from you, but I assure you that my intentions are not to do that. :) I don't Manoj is accusing you of trying to force him to make his rules files not be Makefiles. He's accusing you of trying to let other people make *their* rules files non-Makefiles, which is objectionable to him, because he likes to play with MAKEFLAGS and VPATH. I disagree with him, however, since Policy does not forbid, even implicitly, a developer from sabotaging the values of these variables in the rules file. In my opinion, Manoj's rationale for not tolerating alternative implementations of make is not grounded on any documented interface, but rather his knowledge of what's going on *behind* the interface. Good programmers know not to take such things for granted. Unless Manoj can come up with a different argument that I find persuasive, I would continue to support a proposal to loosen the definition of a debian/rules file in this respect. -- G. Branden Robinson|Lowery's Law: Debian GNU/Linux |If it jams -- force it. If it [EMAIL PROTECTED] |breaks, it needed replacing anyway. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Bug#88029: Package which uses jam (instead make)
On Mon, Oct 20, 2003 at 12:35:04AM +0200, Josip Rodin wrote: On Sun, Oct 19, 2003 at 03:58:19PM -0500, Steve Greenland wrote: I've yet to see a technical argument for allowing debian/rules to be a non-makefile. I've yet to see a technical argument for disallowing debian/rules from being a non-makefile. (itinerant policy-editor hat on) Me neither. -- G. Branden Robinson|Humor is a rubber sword - it allows Debian GNU/Linux |you to make a point without drawing [EMAIL PROTECTED] |blood. http://people.debian.org/~branden/ |-- Mary Hirsch signature.asc Description: Digital signature
Bug#212814: please clarify 3.4: description of a package
On Fri, Sep 26, 2003 at 10:55:44AM +0200, Matthias Klose wrote: Package: debian-policy Version: 3.6.1.0 Severity: wishlist triggered by #209693, the question is, if the long description should be understandable on its own, or together with the short description. Description: Documentation for an array processing package for Python This package contains the manual in PDF format. Clearly the long description is unreadable by itself. lintian on the other hand does check, if the short description is repeated in the long description. Proposing a change like: the long description should always be displayed together with the synopsis, there is no need to repeat the synopsis in some form in the long description. I believe package management utilities are allowed to omit the short description in favor of the long one for interface considerations. The package's short description should not be a sentence. The long description should be one sentence at the VERY least. -- G. Branden Robinson| Men are born ignorant, not stupid. Debian GNU/Linux | They are made stupid by education. [EMAIL PROTECTED] | -- Bertrand Russell http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#212814: please clarify 3.4: description of a package
On Fri, Sep 26, 2003 at 11:02:17PM +0300, Richard Braakman wrote: On Fri, Sep 26, 2003 at 10:50:41AM -0500, Branden Robinson wrote: I believe package management utilities are allowed to omit the short description in favor of the long one for interface considerations. Why, though? What good does it do? The long description is already long (hence the name), so using one more line to add the short description won't hurt anything. And writing good descriptions is a lot easier if you can assume the long description will be read in the context provided by the package name and the short description. Well, I think we should poll the current package manager maintainers (synaptic, gnome-apt, aptitude, etc.) before we such a decision. Other than that I have no objection. -- G. Branden Robinson| I am only good at complaining. Debian GNU/Linux | You don't want me near your code. [EMAIL PROTECTED] | -- Dan Jacobson http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: propose new virtual package: libxaw-dev
[Followups set.] On Thu, Sep 18, 2003 at 09:00:03PM -0500, Craig P. Steffen wrote: I am prospective DD; as one of my opening packages, I intend to adopt the sound file editor xwave. One of the bugs against it, 170005, says that depending on the virtual package libxaw-dev is wrong. However, reading the debian policy manual sections 3.6 and 7.4, it seems to me to be a perfectly reasonable thing to do. The real packages libxaw6-dev and libxaw7-dev exist, and are listed as Providing libxaw-dev. The only other thing that the policy manuals suggest is that virtual packages be mentioned in the virtual-packages-name-list.txt. So I propose that libxaw-dev be added to that list. I disagree; instead, I'm going to kill off libxaw-dev. My decision to use the libxaw-dev virtual package in the first place appears to date back to the time when we had multiple implementations of the Athena library (NeXTaw, Xaw95, and Xaw3D). The -dev packages for these implementations could not coexist with each other, nor with libXaw6's -dev package, because all of them tried to provide /usr/X11R6/lib/libXaw.so for compile-time linking. This is no longer a problem. NeXTaw and Xaw95 have been withdrawn from the distribution, and Xaw3D now uses the shared object name libXaw3d. The only two packages that will collide with each other now are libxaw6-dev and libxaw7-dev, both of which are under my control. A virtual package is not needed to coordinate between two packages I maintain. Thanks for bringing this to my attention. -- G. Branden Robinson| I suspect Linus wrote that in a Debian GNU/Linux | complicated way only to be able to [EMAIL PROTECTED] | have that comment in there. http://people.debian.org/~branden/ | -- Lars Wirzenius signature.asc Description: Digital signature
Bug#209855: [PROPOSAL] Move documentation of behavior of ancient dpkg in 6.6 to a footnote
On Tue, Sep 09, 2003 at 11:22:55PM +0200, Andreas Metzler wrote: -- --- CVS/debian-policy/policy.sgml Sat Aug 23 22:23:53 2003 +++ policy.sgml Tue Sep 9 17:27:00 2003 @@ -3648,10 +3648,18 @@ p If there is no most recently configured version - prgndpkg/prgn will pass a null argument; older versions - of dpkg may pass ttlt;unknowngt;/tt (including the - angle brackets) in this case. Even older ones do not pass a - second argument at all, under any circumstances. + prgndpkg/prgn will pass a null argument. + footnote + p +Historical note: Truly ancient (pre-1997) versions of +prgndpkg/prgn passed ttlt;unknowngt;/tt (including +the angle brackets) in this case. Even older ones did not +pass a second argument at all, under any circumstance. Note +that upgrades using such an old dpkg version are unlikely to +work for other reasons, even if this old argument behavior +is handled by your postinst script. + /p + /footnote /p /sect Seconded. Until and unless I say otherwise, the footnote text can be amended arbitrarily, or even deleted entirely, without invalidating my second. -- G. Branden Robinson| Organized religion is a sham and a Debian GNU/Linux | crutch for weak-minded people who [EMAIL PROTECTED] | need strength in numbers. http://people.debian.org/~branden/ | -- Jesse Ventura pgp4ZuBaTE71H.pgp Description: PGP signature
Re: Move documentation of behavior of ancient dpkg in 6.6 to a footnote (was: /etc/shells management)
On Tue, Sep 09, 2003 at 05:38:51PM +0200, Andreas Metzler wrote: Ok. Redirecting to debian-policy. Please follow the Policy amendment process. apt-get install debian-policy and then view: file:///usr/share/doc/debian-policy/policy-process.html/index.html -- G. Branden Robinson|Humor is a rubber sword - it allows Debian GNU/Linux |you to make a point without drawing [EMAIL PROTECTED] |blood. http://people.debian.org/~branden/ |-- Mary Hirsch pgpXQKdPnbDMe.pgp Description: PGP signature
Re: what is policy about?
On Wed, Aug 27, 2003 at 02:41:19PM +1000, Anthony Towns wrote: Again: there is _no_ need to think of policy as a stick to beat people over the head with. We're _all_ sensible people who want to make Debian the highest quality software distribution in existance, even if we might disagree on how to go about it. We don't need to coerce people with threats for every trivial little thing, and it's probably actively harmful to try to do so. Policy's at its best when it simply says what should be done, and explains why doing other things isn't as good; not when it declares such-n-such must be done, lest the wrath of the release manager descend upon you all. Then we need to get rid of the serious severity in the BTS, or redefine it to omit any mention of Debian Policy. As long as that severity exists in its current form, Policy *will* continue to be used as a stick. A fairly large one, at that. I reiterate my position from last year: * decouple the Policy manual from bug severities * decouple bug severities from release management Neither of these mean that the Policy Manual or Release Manager have to give up any power whatsoever. -- G. Branden Robinson| Yesterday upon the stair, Debian GNU/Linux | I met a man who wasn't there. [EMAIL PROTECTED] | He wasn't there again today, http://people.debian.org/~branden/ | I think he's from the CIA. pgp71V9sFnZJg.pgp Description: PGP signature
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
Re: Bug#197835: [PROPOSAL]: integrated environments are allowed
On Thu, Jun 19, 2003 at 09:19:50AM -0400, Peter S Galbraith wrote: Colin Watson [EMAIL PROTECTED] wrote: I haven't thought very much about Colin Walters' [1] points about editors as embeddable components yet, [1] Damn, this is confusing. Maybe the two of us should avoid getting involved in the same discussions in the future. :-) On the contrary, when you both participate I'm reminded that you are two distinct people. :-) It would help if I met you both in person... http://necrotic.deadbeast.net/~branden/toronto/debconf/10.html Colin Walters is on the left. Colin Watson is on the right. -- G. Branden Robinson| Life is what happens to you while Debian GNU/Linux | you're busy making other plans. [EMAIL PROTECTED] | -- John Lennon http://people.debian.org/~branden/ | pgpzVh1sI836X.pgp Description: PGP signature
Bug#160827: syntax of the maintainer name in the Maintainer: field
On Sat, Dec 07, 2002 at 05:33:10PM -0500, Clint Adams wrote: True. It could get away with tossing everything outside angulars or inside brackets, though. The address can be mandated to stay 7bit for now. At any rate, people shouldn't be putting raw Latin1 in these fields. Amen. 7-bit ASCII only. -- G. Branden Robinson| Psychology is really biology. Debian GNU/Linux | Biology is really chemistry. [EMAIL PROTECTED] | Chemistry is really physics. http://people.debian.org/~branden/ | Physics is really math. pgp5xzuORE2nt.pgp Description: PGP signature
Re: Virtual packages
On Fri, Nov 22, 2002 at 01:41:08PM -0600, Manoj Srivastava wrote: I think the current process is that a bunch of maintainers feel there is a need for a virtual package name, and talk to people maintaining related packages, and work out some virtual package names that are then used privately. Once the number, and name, of the virtual packages has stabilized, and the expectation of what all these packages provide in common is hashed out, these names should be documented -- so that a new maintainer, starting with a new, package, that could provide or depend on these virtual packages, has a well known spot to go to to get the list of established virtual package names. I do think we need to re-write the para to state that the list is merely a registry, of sorts, of established virtual package names. Seconded. -- G. Branden Robinson|To Republicans, limited government Debian GNU/Linux |means not assisting people they [EMAIL PROTECTED] |would sooner see shoveled into mass http://people.debian.org/~branden/ |graves. -- Kenneth R. Kahn pgp2a66bivKz5.pgp Description: PGP signature
Bug#170019: debian-policy: Ambiguity in section 11.7.2 (Configuration files: Location)
On Thu, Nov 21, 2002 at 10:39:57PM +1000, Anthony Towns wrote: On Thu, Nov 21, 2002 at 12:40:32PM +0100, Josip Rodin wrote: Frankly, it should be enough to simply mandate /etc for all configuration files, I don't know why we keep this exception for other directories. Technically, it's enough to mandate /etc, but suggesting the use of symlinks from /usr might make life a bit easier for some maintainers who are aghast at the thought of rewriting upstream to use /etc natively. *cough*143825*cough* *cough*Patches welcome.*cough* -- G. Branden Robinson|You should try building some of the Debian GNU/Linux |stuff in main that is [EMAIL PROTECTED] |modern...turning on -Wall is like http://people.debian.org/~branden/ |turning on the pain. -- James Troup pgpPrHiiycDUH.pgp Description: PGP signature
Re: CVS branden: Branden
On Wed, Nov 20, 2002 at 12:10:00AM +0100, Josip Rodin wrote: On Tue, Nov 19, 2002 at 11:00:41PM -0700, debian-policy@lists.debian.org wrote: CVSROOT:/org/cvs.debian.org/cvs/debian-policy Module name:debian-policy Changes by: branden Tue Nov 19 16:00:41 MST 2002 Modified files: . : policy.sgml Log message: Branden * Change markup of gzip -9 to a kbd element everywhere. I said kbd would be used in HTML. This is not HTML. :) Then confine your nitpicks to that which is relevant, damnit. I don't know what all tags there are in DebianDoc-SGML. I'll change all these kbd tags to josip tags an expect you to fix it. No, don't tell me how to fix it. Fix it yourself. Your honor will then be restored. This will teach me to listen to someone who is obsessively pedantic over proper usage of SGML tags -- they'll just wander off on some stupid tangent and wax preachy about how they'd pedantically do things if we wen're using SGML. :-P -- G. Branden Robinson| You could wire up a dead rat to a Debian GNU/Linux | DIMM socket and the PC BIOS memory [EMAIL PROTECTED] | test would pass it just fine. http://people.debian.org/~branden/ | -- Ethan Benson pgpdpmC3wiuw3.pgp Description: PGP signature
Re: Bug#169399: handling of additional documentation with doc-base
On Mon, Nov 18, 2002 at 11:56:51AM +, Andrew Suffield wrote:
On Sun, Nov 17, 2002 at 07:39:52PM -0500, Branden Robinson wrote:
b) what severity such bugs should be
I strongly disagree with this. I wrote up an extensive explanation of
why recently:
http://lists.debian.org/debian-ctte/2002/debian-ctte-200211/msg00027.html
Hmm, wretched limited debbugs semantics. How about ranges?
{RC, (serious/important/normal/minor), wishlist} or similar. That still
covers all the cases, I think.
As you may be able to deduce from the message I cited, I am
uncomfortable with the Policy manual mandating bug severities in any
way.
I think such things are better left to the documentation of the BTS
itself.
--
G. Branden Robinson| If God had intended for man to go
Debian GNU/Linux | about naked, we would have been
[EMAIL PROTECTED] | born that way.
http://people.debian.org/~branden/ |
pgpaAChDt4AFt.pgp
Description: PGP signature
Re: Bug#169399: handling of additional documentation with doc-base
[Sending this to -policy instead of the bug.] On Sun, Nov 17, 2002 at 06:02:10AM +, Andrew Suffield wrote: On Sun, Nov 17, 2002 at 02:45:36AM +0100, Josip Rodin wrote: Speaking of bugs... how do we actually specify that a should means e.g. minor, and not normal or important? I suggest that the old RFC-style must/should/may syntax be dropped when policy is next rewritten, in favour of a system which describes accurately: a) whether breaking this rule is a bug, or whether this is just documentation I think we should: 1) Do as you suggest; and/or 2) *Consistently* use must/should/may in the RFC-way, and document what we mean by these words in a preface to the Policy Manual. In other words, I think informative footnotes about what breaks (if anything) when a policy is not followed are useful, and orthogonal to whether we decide RFC-style must/should/mays are useful. b) what severity such bugs should be I strongly disagree with this. I wrote up an extensive explanation of why recently: http://lists.debian.org/debian-ctte/2002/debian-ctte-200211/msg00027.html -- G. Branden Robinson| There is no gravity in space. Debian GNU/Linux | Then how could astronauts walk [EMAIL PROTECTED] | around on the Moon? http://people.debian.org/~branden/ | Because they wore heavy boots. pgp8AqB0oH6eU.pgp Description: PGP signature
Bug#165063: debian-policy: Section `12.8.3 Packages providing a terminal emulator' fails to sufficently document the -e option
On Fri, Nov 15, 2002 at 09:30:35PM -0500, Branden Robinson wrote: On Fri, Nov 15, 2002 at 09:41:15AM +, Jonathan David Amery wrote: I suggest that the following patch be applied to policy in order to resolve this issue: --- policy.sgml.old Fri Nov 15 09:30:47 2002 +++ policy.sgml Fri Nov 15 09:36:16 2002 @@ -6982,9 +6982,12 @@ emulator application were so coded, be a new view in a multiple-document interface (MDI). /p /footnote - and runs the specified varcommand/var. + and runs the specified varcommand/var, + interpreting the entirity of the rest of the command + line as a command to pass straight to exec, in the + manner that ttxterm/tt does. /p/item itemp Support the command-line option tt-T Seconded. It has been pointed out to me that: s/entirity/entirety/ -- G. Branden Robinson| When dogma enters the brain, all Debian GNU/Linux | intellectual activity ceases. [EMAIL PROTECTED] | -- Robert Anton Wilson http://people.debian.org/~branden/ | pgpBJIxuJ1KPc.pgp Description: PGP signature
Re: Bug#167004: My counter-proposal
On Sun, Nov 17, 2002 at 12:47:41PM -0500, Colin Walters wrote: On Sun, 2002-11-17 at 10:04, Christian Marillat wrote: Hi, We simply add 40 points if a window manager is compliant with The Window Manager Specification Project instead of 20. this will solve the metacity problem. Seconded. I second this as long as people swear to stop bitching at me about what window manager ends up as the default. :-P -- G. Branden Robinson|I'm sorry if the following sounds Debian GNU/Linux |combative and excessively personal, [EMAIL PROTECTED] |but that's my general style. http://people.debian.org/~branden/ |-- Ian Jackson pgpfdQVuOy9rO.pgp Description: PGP signature
Re: Bug#167422: files in /usr/share should be world-readable
On Thu, Nov 14, 2002 at 06:13:50PM -0600, Manoj Srivastava wrote: Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden Well, according to the FHS, you shouldn't be putting variabel data in Branden /usr at all: It is not variable data. It is static data; that does not change after installation. /usr/ is allowed to change when you install a new package. It still seems wrong to have log files in /usr. Are the files ever accessed by anything other than the user? I.e., do the install logs contain information that is useful to Emacs itself? -- G. Branden Robinson| There's nothing an agnostic can't Debian GNU/Linux | do if he doesn't know whether he [EMAIL PROTECTED] | believes in it or not. http://people.debian.org/~branden/ | -- Graham Chapman pgpiwsRmBwCMV.pgp Description: PGP signature
Re: Bug#167422: files in /usr/share should be world-readable
On Fri, Nov 15, 2002 at 02:13:23AM -0600, Manoj Srivastava wrote: If these were ordinary log files of a running program generating data, I may agree. But since we are down to gut feelings, a bunch of files are generated by postinst, and they all reside in the same place. Some of these files are read by emacs; some times there is a README read by the inquisitive users, and then there is a record of what transpired while gemerating these files. It strikes my gut as sane that these files, all generated by the postinst, live in the same location. [...] They are not even accessed by the user directly, and certainly not by emacs. This description unambiguously screams /var/log to me. Clearly your mileage varies. -- G. Branden Robinson| Debian GNU/Linux | Please do not look directly into [EMAIL PROTECTED] | laser with remaining eye. http://people.debian.org/~branden/ | pgpAFxq6xFn9a.pgp Description: PGP signature
Bug#165063: debian-policy: Section `12.8.3 Packages providing a terminal emulator' fails to sufficently document the -e option
On Fri, Nov 15, 2002 at 09:41:15AM +, Jonathan David Amery wrote: I suggest that the following patch be applied to policy in order to resolve this issue: --- policy.sgml.old Fri Nov 15 09:30:47 2002 +++ policy.sgml Fri Nov 15 09:36:16 2002 @@ -6982,9 +6982,12 @@ emulator application were so coded, be a new view in a multiple-document interface (MDI). /p /footnote - and runs the specified varcommand/var. + and runs the specified varcommand/var, + interpreting the entirity of the rest of the command + line as a command to pass straight to exec, in the + manner that ttxterm/tt does. /p/item itemp Support the command-line option tt-T Seconded. -- G. Branden Robinson|I'm sorry if the following sounds Debian GNU/Linux |combative and excessively personal, [EMAIL PROTECTED] |but that's my general style. http://people.debian.org/~branden/ |-- Ian Jackson pgpYD5GJ3sYeB.pgp Description: PGP signature
Re: Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On Wed, Nov 13, 2002 at 12:14:50AM -0600, Manoj Srivastava wrote: There is a proposal under consideration for changing the undocumented(7) man page. The current proposal is included below; it is not yet the final form; and input of the general community is solicited. I have brought this modification to the notice of the full developer list since I think that this may impact a number of people, including users, whose views should be taken into account. I personally find the undocumented (7) man page frustrating, since I expected to see documentation, and was told there was none after a wait (yes, I had a slow machine). I would have much rather not had my hopes raised, and that man itself told me there was no manual page. In any case, please follow up to the address given. When declaring a comment period, it is customary to announce when it will end. How long do you propose to wait before declaring this proposal non-objectionable? So far I haven't seen any complaints that wouldn't be addressed by Colin Watson's planned update to the man-db package. -- G. Branden Robinson|The basic test of freedom is Debian GNU/Linux |perhaps less in what we are free to [EMAIL PROTECTED] |do than in what we are free not to http://people.debian.org/~branden/ |do. -- Eric Hoffer pgpLFXx1OSGK8.pgp Description: PGP signature
Bug#167422: files in /usr/share should be world-readable
On Thu, Nov 14, 2002 at 01:57:43AM -0600, Manoj Srivastava wrote: Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden I don't have one any more specific than somewhere under /var. Branden /var/log doesn't work if the byte-compiler isn't running as the root Branden user or the adm group. Branden *Does* the byte-compiler run as root? I dunno. I think I prefer the log file to be in the same place as the elc files; and not clutter up /var/log (which would be the logical place under var). Besides, unlike /var/log. which is not shareable between systems, these compilation logs are indeed shareable, and as such, belong in a shareable area. Well, according to the FHS, you shouldn't be putting variabel data in /usr at all: Here is a summarizing chart. This chart is only an example for a common FHS-compliant system, other chart layouts are possible within FHS- compliance. +-+-+-+ | | shareable | unshareable | +-+-+-+ |static | /usr| /etc| | | /opt| /boot | +-+-+-+ |variable | /var/mail | /var/run| | | /var/spool/news | /var/lock | +-+-+-+ Admittedly, the FHS is giving you piss-poor alternatives. But it seems that /usr-anything is wrong. -- G. Branden Robinson|Religion is regarded by the common Debian GNU/Linux |people as true, by the wise as [EMAIL PROTECTED] |false, and by the rulers as useful. http://people.debian.org/~branden/ |-- Lucius Annaeus Seneca pgpyNwifxejWD.pgp Description: PGP signature
Re: Bug#167422: files in /usr/share should be world-readable
On Wed, Nov 13, 2002 at 12:17:48AM -0600, Manoj Srivastava wrote: Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden On Sat, Nov 09, 2002 at 08:10:02PM -0600, Manoj Srivastava wrote: You can decide not to log for _your_ package. I certainly am going to continue to log the compilation for mine. Branden Well, will you consider placing them in a more FHS-friendly location Branden than /usr/share? :) The log file lives in the same place as the generated e;c files; I consider them all as files generated while bytecompiling. What was your recommendation? I don't have one any more specific than somewhere under /var. /var/log doesn't work if the byte-compiler isn't running as the root user or the adm group. *Does* the byte-compiler run as root? -- G. Branden Robinson| Communism is just one step on the Debian GNU/Linux | long road from capitalism to [EMAIL PROTECTED] | capitalism. http://people.debian.org/~branden/ | -- Russian saying pgpZ0RHzirOUL.pgp Description: PGP signature
Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On Wed, Nov 13, 2002 at 12:14:50AM -0600, Manoj Srivastava wrote: There is a proposal under consideration for changing the undocumented(7) man page. The current proposal is included below; it is not yet the final form; and input of the general community is solicited. I have brought this modification to the notice of the full developer list since I think that this may impact a number of people, including users, whose views should be taken into account. Well, no one appears to have really objected. Response on -devel has been neutral to positive. I say we go with it. As a newly appointed Policy editor, I have the power to enforce my will. /me pauses for a moment, watching the waves of horror break over debian-devel :) However, since Manoj took point on this issue I'll defer to his judgement as to when the comment period should end. Unless he wants to delegate the conclusion of this matter to one of the other editors (Julian, Josip, or me). (...ah, this post was worth it just for the wicked grin I had on my face while writing it. :) ) -- G. Branden Robinson| I suspect Linus wrote that in a Debian GNU/Linux | complicated way only to be able to [EMAIL PROTECTED] | have that comment in there. http://people.debian.org/~branden/ | -- Lars Wirzenius pgpab97W8JXzr.pgp Description: PGP signature
Re: Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On Wed, Nov 13, 2002 at 09:50:12AM -0600, Manoj Srivastava wrote: I would prefer not to make that a recommendation. Those patches are accepted, of course, but I do really prefer sgml diffs. I am not about to make it a requirement, but I'd rather not recommend something that goes against making less work for the editor. I don't think this is a big deal, really, do you? I think now that we have Josip as an editor, he can pick any SGML diffs free of nits. :) -- G. Branden Robinson| Debian GNU/Linux | Ab abusu ad usum non valet [EMAIL PROTECTED] | consequentia. http://people.debian.org/~branden/ | pgpXvQFO0i8SP.pgp Description: PGP signature
Re: Bug#167422: files in /usr/share should be world-readable
On Sat, Nov 09, 2002 at 08:10:02PM -0600, Manoj Srivastava wrote: You can decide not to log for _your_ package. I certainly am going to continue to log the compilation for mine. Well, will you consider placing them in a more FHS-friendly location than /usr/share? :) -- G. Branden Robinson| Suffer before God and ye shall be Debian GNU/Linux | redeemed. God loves us, so He [EMAIL PROTECTED] | makes us suffer Christianity. http://people.debian.org/~branden/ | -- Aaron Dunsmore pgp7NBHqSmGay.pgp Description: PGP signature
Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
I second the proposal in [EMAIL PROTECTED]. -- G. Branden Robinson|You can have my PGP passphrase when Debian GNU/Linux |you pry it from my cold, dead [EMAIL PROTECTED] |brain. http://people.debian.org/~branden/ |-- Adam Thornton pgpzFL2o2b5a8.pgp Description: PGP signature
Re: Bug#97671: xutils: why is rstart.real a conffile?
, but that's not in and of itself determinative of whether you care about it or not. Sounds like a good candidate for a tag, to me. You care about the bug, you put (or keep) the tag on. You stop caring about the bug, you tear the tag off. Your tag, your call. The package maintainer will know that your eyes are on that bug. [Consider our recent discussion regarding 4.2.1-3, #97671, and propagation testing. Among other things I didn't know, I didn't know if you were still paying attention to that bug or not. With this tag, I'd have known. Unless you stopped caring and forgot to take it off. :) But that's more easily rectified (I mail you about it and you reply I don't care about this anymore and CC [EMAIL PROTECTED] to strip the tag) than the converse, where you care about some bugs but the package maintainer doesn't know you do.] ( Hrm, an allow-release tag might be a better way of doing things than ) ( checking there aren't more bugs in unstable than there are in testing. ) I'm not wedded to the name or semantics of a release-critical tag. I think the right thing to do is to equip the BTS with a device that lets the Release Manager do his job efficiently. I think a tag is it. What it's named and what it means should be left mostly up to the RM. (I say mostly because I think I might object to a tag called fucked being applied to one of my packages. :) ) I don't believe there's any real value in changing the BTS to treat ignored bugs specially in a way that would be useful for Branden's triage; By the same token, I don't think there's any real value in having the BTS treat policy violations specially for triage purposes. At least not with Policy in its current form. I may very well feel differently if Manoj succeeds in thrusting his trident into the sea, threading the conch shell, and bringing down a new Policy from Mount Sinai that's so elegant it makes me weep in admiration. :) although generalising it to allow the maintainer to arbitrarily re-prioritise bugs would probably be a win -- the idea being you could use a different URL and get the bugs in the order in which the maintainer will be focussing on them. (Which is to say, I won't be writing or applying any patches for the former, although someone else on [EMAIL PROTECTED] might, but I'd probably be interested in seeing patches or good ideas for the latter) Bugzilla has two different fields. Severity and Priority. I'm pretty sure I think that's a good idea, but as you say, you're not willing to do it. I don't know of anyone else who is, either. Let us not let the vision of an ideal future BTS hamstring its operation for us now. We should not aggravate our suffering of miserable severity flamewars as some sort of masochistic punishment for not implementing certain features in the BTS. Let the BTS be designed to work well for us today, not against a future where we have a universally-agreed upon Policy Manual in which must is never used where should will suffice. When that day comes, it's easy to tighten up the definition of serious if we want to. Assuming the pending tag on Bug#143825 is for triage (since it hasn't been closed in any of the uploads since the tag was applied) it's probably better to add [lowpri] to the bug's subject, then use http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xutilsexclude=subj:[lowpri] to get the sanitized page. An inaccurate pending tag probably makes it less likely for people to provide patches, etc, which would presumably be a loss. Apologies if the assumption's incorrect, of course. It's not inaccurate; it's there to tell people curious about the bug that I agree that it's a bug, it's been triaged, I'm aware of it, and that I intend to fix it. It's just not a high-priority item. I want to fix it right, which means Imake tweakage. Imake doesn't really know about FHS[2], which is suboptimal. If it did, this problem, along with others I dare not point out for fear of more and redundant serious bugs getting filed, will go away. Such a fix might also make it easier for Debian to transition to shipping XFree86 in /usr instead of /usr/X11R6. Ooh, now *there's* a way to get Manoj to support lowering the severity of this bug. ;-) It won't be hard to fix Imake in this way. Just tedious. I intend to get to it before the next freeze. [1] I qualify with largely because there will always be people who split hairs over the meanings of simple words. In arguing against the concept of objective severities, I won't be so cruel to my opposition as to hold them to a standard of *perfect* objectivity. I just think that it's very hard to attain even a moderate level of objectivity, and that at present we haven't reached it. [2] It knows about bits of it. My plan is to have a UseFHS expando and set a bunch of defines, probably in X11.tmpl, if it evaluates true. Then of course one has to change linux.cf and any other .cf for which the FHS might be relevant. -- G. Branden
Bug#168435: debian-policy: Remove the requirement to install static libraries
On Sat, Nov 09, 2002 at 04:25:00PM +0100, Sebastian Rittau wrote: Package: debian-policy Version: 3.5.7.0 Severity: wishlist I suggest the following alteration to the policy: I object strenuously to this proposal. + All libraries must have a shared version in the + ttlib*/tt package and may have a static version in the + ttlib*-dev/tt package. Rationale: The removed paragraph was redundant with the first paragraph of the section and was moved there. You've made it a violation of policy to *not* provided a shared version of a library. Some libraries aren't intended to have shared versions available. For instance, see the package description of xlibs-dev: xlibs-dev provides static versions of the libraries provided in xlibs, as well as several libraries that do not exist in shared object form for various reasons (such as the fact that their APIs have not stabilized, or that they are deprecated). Header files and manual pages are also provided. Also see libtwofish-dev. The main aspect of this proposal is the removed requirement of including static versions of each library in the corresponding -dev package. Many modern libraries don't work well as a static library and usage of static libraries should be deprecated except for a few specific cases. Cite examples. This policy change would allow maintainers to decide for themselves, whether a static version of their library is useful, thereby decreasing the size of many -dev packages and in turn decreasing download time and archive size. In the rare cases, where a static library is needed and the package maintainer doesn't provide it, the user can either request the inclusion from the maintainer or compile the library his/herself. The user can do all kinds of things for hisself [sic]; Debian tries to make such things straightforward. How about a policy proposal that simply clears up the redundancy rather than pursuing a private agenda as a bonus? -- G. Branden Robinson| It just seems to me that you are Debian GNU/Linux | willfully entering an arse-kicking [EMAIL PROTECTED] | contest with a monstrous entity http://people.debian.org/~branden/ | that has sixteen legs and no arse. pgpF86962FvLY.pgp Description: PGP signature
Bug#167004: add ewmh-x-window-manager alternative, drop EWMH section from priority, add virtual package ewmh-x-window-manager
On Tue, Oct 29, 2002 at 08:41:44PM -0500, Colin Walters wrote: It turns out that just bumping the priority of x-window-managers like metacity which implement the EWMH spec isn't enough. Other window managers like twm still take priority, mainly because they support the Debian menu system directly (which metacity doesn't, it relies on the GNOME panel to do it). So I think what we really need is an ewmh-x-window-manager, that packages like gnome-wm can use to explicitly invoke a window manager which supports the EWMH spec. Ugh, I don't like this. Please just play with the scoring of EWMH support instead. Depends: metacity | ewmh-x-window-manager | x-window-manager? Ugh. -- G. Branden Robinson|I'm sorry if the following sounds Debian GNU/Linux |combative and excessively personal, [EMAIL PROTECTED] |but that's my general style. http://people.debian.org/~branden/ |-- Ian Jackson pgpHnifPJfHJr.pgp Description: PGP signature
Bug#167004: gnome-wm
On Wed, Oct 30, 2002 at 01:39:22PM -0800, Chris Waters wrote: On Wed, Oct 30, 2002 at 03:29:09PM +0100, Christian Marillat wrote: I think the best choice is to increase the value to 30 or 40 if a window manager complies with the Window Manager Specification Project and keep only one alternative for window manager. No. Such compliance only helps if you're using a window manager with one of these desktop environments. You're going to face fierce (and well-deserved) opposition to any such proposal. Look, any desktop environment worth its salt provides session management functions, and thus one of its packages can register itself as an x-session manager. Once that is done /etc/X11/Xsession gets out of the way and hands control over to the session manager. The session manager can then do whatever it likes to determine which window manager should be run, probably using x-window-manager as a final fallback before erroring out with a complaint that it could find window manager at all. This solution would completely eliminate the need for any policy changes. However, it may be a less than obvious solution because some of the x-display-manager package maintainers in Debian refuse to use /etc/X11/Xsession as the default X session script. -- G. Branden Robinson| Debian GNU/Linux | De minimis non curat lex. [EMAIL PROTECTED] | http://people.debian.org/~branden/ | pgpHwbrffmUr3.pgp Description: PGP signature
Bug#165063: debian-policy: Section `12.8.3 Packages providing a terminal emulator' fails to sufficently document the -e option
On Fri, Oct 18, 2002 at 12:41:28AM +0100, Jonathan Amery wrote: It doesn't interpret the command line after the -e option the same way that xterm does: xterm -e less .bash_profile runs `less .bash_profile' in a new terminal window whereas gnome-terminal -e less .bash_profile runs `less' in a new terminal window (and doesn't appear to do anything useful with the .bash_profile argument at all). gnome-terminal -e 'less .bash_profile' works of course, but that doesn't work for xterm. Okay, I get it. Yes, clarification is required. I guess we have to mandate that -e be treated as the last x-terminal-emulator option, eh? -- G. Branden Robinson| Never attribute to malice that Debian GNU/Linux | which can be adequately explained [EMAIL PROTECTED] | by stupidity. http://people.debian.org/~branden/ | pgpt3Bg5kWCFL.pgp Description: PGP signature
Bug#165063: debian-policy: Section `12.8.3 Packages providing a terminal emulator' fails to sufficently document the -e option
On Fri, Oct 18, 2002 at 01:52:49AM -0400, Clint Adams wrote: Okay, I get it. Yes, clarification is required. I guess we have to mandate that -e be treated as the last x-terminal-emulator option, eh? That won't help with the quoting. Feel free to read what I wrote as support the -e option as xterm does. j -- G. Branden Robinson| The last Christian died on the Debian GNU/Linux | cross. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | pgpWw8iI2vMxl.pgp Description: PGP signature
Bug#165063: debian-policy: Section `12.8.3 Packages providing a terminal emulator' fails to sufficently document the -e option
On Wed, Oct 16, 2002 at 05:49:15PM +0100, Jonathan David Amery wrote: The current: * Support the command-line option -e command, which creates a new terminal window[53] and runs the specified command. doesn't distinguish between gnome-terminal's -e option and xterm's -e option, which are incompatible. (gnome-terminal provides a wrapper to fix this problem). What's to distinguish? Does gnome-terminal's -e option *not* create a new terminal window and run the specified command? The policy is telling you what your -e option must do for you to be able to call yourself an x-terminal-emulator. -- G. Branden Robinson| Q: How does a Unix guru have sex? Debian GNU/Linux | A: unzip;strip;touch;finger;mount; [EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck; http://people.debian.org/~branden/ |umount;sleep pgpffHcXaRDto.pgp Description: PGP signature
Bug#164035: debian-policy: [PROPOSAL] build-dependencies should be satisfied during the clean target
On Thu, Oct 10, 2002 at 12:44:52AM +0100, Andrew Suffield wrote: `Build-Depends', `Build-Conflicts' The `Build-Depends' and `Build-Conflicts' fields must be satisfied when any of the following targets is invoked: `build', - `binary', `binary-arch', `build-arch', `build-indep' and + `binary', `binary-arch', `clean', `build-arch', `build-indep' and `binary-indep'. `Build-Depends-Indep', `Build-Conflicts-Indep' The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must be satisfied when any of the following targets is invoked: - `build', `build-indep', `binary' and `binary-indep'. + `build', `build-indep', `clean', `binary' and `binary-indep'. Seconded. -- G. Branden Robinson| Never underestimate the power of Debian GNU/Linux | human stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | pgpBxdTbb3YdG.pgp Description: PGP signature
Bug#162120: debian-policy: Deletion of configuration files--should it be preserved?
On Wed, Sep 25, 2002 at 12:38:22PM +1000, Anthony Towns wrote: Why the fuck do we have to have a debate about this? A wise man once said something like, how hard is it to give the reasons why you object to the suggestion, rather than just puffing out your chest and declaring your opposition? -- G. Branden Robinson| You don't just decide to break Debian GNU/Linux | Kubrick's code of silence and then [EMAIL PROTECTED] | get drawn away from it to a http://people.debian.org/~branden/ | discussion about cough medicine. pgpVLNBWhErBs.pgp Description: PGP signature
Re: [RFC] *-rc.d - rc.d-* transition
On Sun, Sep 08, 2002 at 07:20:31PM -0400, Joey Hess wrote: I dislike the rc.d anywhere in the name on general aestetic principles, but Chris's arguments about the update- prefix are persuasive to me. I'd much rather see the rc.d name dropped where possible for init, so we'd have invoke-init, update-init and so on. I second this. Moreover, I think it's a good idea because we want to standardize around one set of tools for Debian packages (and even users) to invoke when they need to interact with the init system in this fashion, and we shouldn't really care about whether the underlying init system uses file rcs or rc directories or whatever. If we think ahead just a little, then we won't have scripts named a certain way for historical reasons which may not apply when someone has swapped out System V init for something else, perhaps based on a very different technology. The important thing is the functionality. I'm neutral on the issue of whether the verb or noun should come first. * On the one hand, having the noun first nicely groups related system functions together, and may be more helpful to people using tab completion. * On the other hand, there's a fair about of Debian inertia in the other direction. update-this, update-that, update-foo, update-bar. I myself have contributed to his inertia, unfortunately. (update-fonts-alias et al.) I prefer the former, but if people are going to have a hissy fit about it, then I can abandon that. My preference for update-init over update-rc.d is much greater than my preference for init-update over update-init. -- G. Branden Robinson|To Republicans, limited government Debian GNU/Linux |means not assisting people they [EMAIL PROTECTED] |would sooner see shoveled into mass http://people.debian.org/~branden/ |graves. -- Kenneth R. Kahn pgpVPRNm6yp67.pgp Description: PGP signature
Re: Debian LSB Status
On Thu, Aug 29, 2002 at 08:24:25AM +1000, Anthony Towns wrote: Debian 3.0r0 (woody), is close, but not quite, in compliance with LSB 1.2. The outstanding issues are: [snip] Thanks for this extremely informative report. It had been my understanding that our init system and/or runlevels were an issue as well; is that a part of the spec we don't have to comply with for the specific certification we are seeking? It certainly seemed the case at DebConf that most of us believed that our init system was a stumbling block to certification. Pointers to any FAQ on this issue are welcome. -- G. Branden Robinson| Yesterday upon the stair, Debian GNU/Linux | I met a man who wasn't there. [EMAIL PROTECTED] | He wasn't there again today, http://people.debian.org/~branden/ | I think he's from the CIA. pgp9i6I7F2BSf.pgp Description: PGP signature
Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Sun, Aug 18, 2002 at 11:52:54PM +0100, James Troup wrote: Yes, but it's complete and utter crap; it was then and still is now. Ben ran a buildd on vore which is one of the faster buildds, but I've run both vore and some of our slower (arm, m68k) buildds and I can guarantee you that the additional time incurred by using '-g' is so insignificant it's insulting to have to even discuss it. The whole -g thing really ought to be fixed; it snuck in AFAICS/R bypassing the proper policy procedure, and is, in any event, entirely bogus. I concur with not forcing maintainers to omit -g. I'd concur with strongly recommending including it, in fact. I don't omit it with XFree86 and I'll be damned if I'm about to start. It's too convenient to be able to hop into my build tree and send someone an unstripped binary with debugging symbols. I'm not giving that up without a fight. I don't have a strong opinion on what -O should be. Simply being able to get a worthwhile backtrace from a core file is so many light years ahead of what we currently support by default (and what Policy purports to mandate) that arguing over the relative merits of stepi versus nexti seems insignificant to me. (BTW, someone's mailer is a complete piece of crap. What the F is up with mangling the subject line like that?) -- G. Branden Robinson| You don't just decide to break Debian GNU/Linux | Kubrick's code of silence and then [EMAIL PROTECTED] | get drawn away from it to a http://people.debian.org/~branden/ | discussion about cough medicine. pgpgA28QGBh4D.pgp Description: PGP signature
Bug#155680: PROPOSAL ] bump priority of window managers which support WMSP
On Mon, Aug 12, 2002 at 10:43:06PM -0400, Colin Walters wrote: Well, are we basically in rough consensus about this now? Here's an updated patch which just makes the priority increase 20 instead of 30. I don't object. -- G. Branden Robinson| I came, I saw, she conquered. Debian GNU/Linux | The original Latin seems to have [EMAIL PROTECTED] | been garbled. http://people.debian.org/~branden/ | -- Robert Heinlein pgperRl9lvLjG.pgp Description: PGP signature
Bug#155680: PROPOSAL ] bump priority of window managers which support WMSP
On Wed, Aug 07, 2002 at 10:44:15AM -0700, Chris Waters wrote: Hmm, 30 points is a lot. That would mean that a netwm-compliant window manager which didn't support the Debian menu system would rank higher than a non-netwm system which did. I'm not sure I'm willing to go that far. Me neither. I definitely have mixed feelings about this whole thing. I'd like gnome to work hassle-free out of the box, but I'd also like to have the *best* window manager be default, even for our users that don't use gnome. I think that a netwm alternative might actually be the best approach all around, even if it is a little more complicated. I am tempted to agree. (I still want to hear what Branden has to say about all of this, too.) I haven't firmly made up my mind yet. Can someone tell me what the relationship between WMSP, netwm, and the EWMH spec is? -- G. Branden Robinson|Religion is regarded by the common Debian GNU/Linux |people as true, by the wise as [EMAIL PROTECTED] |false, and by the rulers as useful. http://people.debian.org/~branden/ |-- Lucius Annaeus Seneca pgpyTbpCSxcoH.pgp Description: PGP signature
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Sun, Jul 28, 2002 at 12:27:38PM +0100, Mark Brown wrote: I wouldn't say so. For example, a C compiler ought to provide /usr/bin/cc in some form or another, You're talking about an alternative for /usr/bin/cc. A thing that compiles C source code into object files is a C compiler regardless of where its binary lives or what it's called. a mail transport agent ought to provide a /usr/sbin/sendmail implementation Only if policy says so. In and of itself this isn't a requirement mandated by the fact that Provides: mail-transport-agent is in a package's control data. and a web server ought to serve things out of /var/www by default. Purely an FHS issue. A web server is a thing that speaks HTTP over a network interface (which may be virtualized). By the way, the virtual package name for a web server is httpd. Other virtual packages appear to be more about ensuring that only one package tries to use a given resource at one time. There's no fundamental reason you couldn't have multiple MTAs listening on different ports, or different web servers on different ports. I don't think that is possible in the former case due to /usr/sbin/sendmail, but that's something we decided to do and not an inherent restriction imposed by the MTAs themselves. I suggest folks simply read Policy 7.4 and understand virtual packages for what they are: no less, and *no more*. However, I give up. Unless the maintainers of the various and sundry DHCP client packages in Debian decide to cooperate there's no way that #154142 can be solved in a way that makes both the submitter and the maintainer happy. Every time a new DHCP client is packaged for Debian a bug will have to be filed against etherconf wailing that some person's favorite DHCP client is unfairly discriminated against. (And worse, when a DCHP client package dies, etherconf will refer to a nonexistent one.) The package's Depends: line will get longer and longer for no particularly good reason, except that some folks have these mystical notions about what a virtual package is good for. I expect you to be calling for the removal of a great many virtual packages listed in /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz, because they define an insufficiently strict interface. pdf-viewer for instance. What possible good is that? It doesn't tell you what it's called or what options to give it! It doesn't even say if you feed the pdf-viewer input on standard in or if it takes the input as argument on its command line! And Lord knows we have to be sure that only one pdf-viewer is installed at a time; there are precious resources that are monopolized by such tools. We need to be enhancing the user experience in Debian by doing away with these meaningless virtual packages! -- G. Branden Robinson|Somebody once asked me if I thought Debian GNU/Linux |sex was dirty. I said, It is if [EMAIL PROTECTED] |you're doing it right. http://people.debian.org/~branden/ |-- Woody Allen pgpByEzsDh7yI.pgp Description: PGP signature
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Sat, Jul 27, 2002 at 11:25:06PM -0400, Sam Hartman wrote: Branden These appear to be equally valid arguments against all Branden other virtual packages in Debian. To mee this is simply an argument that the description entry in the virtual packages list should be carefully written in this (and really all other) case. Perhaps something like DHCP clients compatible with ifup/ifdown This discussion appears to be irrelevant. None of the DHCP client maintainers has said, yes, good idea, I'll do this, therefore it's dead in the water. I doubt that providing a description as you suggest will do anything to overcome Mark Brown's opposition to the idea. -- G. Branden Robinson|A committee is a life form with six Debian GNU/Linux |or more legs and no brain. [EMAIL PROTECTED] |-- Robert Heinlein http://people.debian.org/~branden/ | pgphR0tHl11Fi.pgp Description: PGP signature
make it official
retitle 154142 [PROPOSED] dhcp-client virtual package
reassign 154142 debian-policy
severity 154142 wishlist
thanks
--- virtual-package-names-list.txt~ 2002-07-28 13:11:31.0 -0500
+++ virtual-package-names-list.txt 2002-07-28 13:13:37.0 -0500
@@ -63,6 +63,7 @@
awk Anything providing suitable /usr/bin/{awk,nawk} (*)
c-compiler Anything providing a C compiler
c-shell Anything providing a suitable /bin/csh (*)
+dhcp-client Any package providing a DHCP client
dotfile-module Anything that provides a module for the
Dotfile Generator
dict-client Any package providing clients for the Dictionary Server
I am seeking seconds for this proposal.
--
G. Branden Robinson|
Debian GNU/Linux | If ignorance is bliss,
[EMAIL PROTECTED] | is omniscience hell?
http://people.debian.org/~branden/ |
pgpcEQLeory77.pgp
Description: PGP signature
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Thu, Jul 25, 2002 at 05:09:06PM +0100, Mark Brown wrote: On Thu, Jul 25, 2002 at 10:21:15AM -0500, Branden Robinson wrote: Etherconf never invokes anything other than ifup and ifdown. It's ifup that has the smarts. I know it already handles dhcp-client and pump; i think (but may be wrong) that Branden has seen it work with udhcpc. So what you're saying is that the standard interface should be that provided by ifup and ifdown. No, that's how *etherconf* elects to take advantage of DHCP clients. There's no onus on anything else to work that way. There's nothing particularly wrong with that - it's just that it needs to be know that that's how things work. But it isn't, necessarily. Perhaps some sort of interface description ought to be added to the virtual packages list in policy? I still don't think that is necessary. Do you formally object to the proposed update to the virtual packages list? -- G. Branden Robinson| To stay young requires unceasing Debian GNU/Linux | cultivation of the ability to [EMAIL PROTECTED] | unlearn old falsehoods. http://people.debian.org/~branden/ | -- Robert Heinlein pgpsMONl9ulap.pgp Description: PGP signature
[epg@progeny.com: Bug#154142: dhcp-client conflicts]
- Forwarded message from Eric Gillespie [EMAIL PROTECTED] - From: Eric Gillespie [EMAIL PROTECTED] To: Matt Kraai [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Bug#154142: dhcp-client conflicts Date: Thu, 25 Jul 2002 10:05:09 -0500 Message-Id: [EMAIL PROTECTED] User-Agent: nmh/1.0.4+dev (i386-unknown-netbsdelf1.5ZA) Matt Kraai [EMAIL PROTECTED] writes: Suppose that no common interface is provided: if etherconf doesn't know how to invoke udhcpc, then having udhcpc provide dhcp-client will break etherconf's DHCP support. Etherconf never invokes anything other than ifup and ifdown. It's ifup that has the smarts. I know it already handles dhcp-client and pump; i think (but may be wrong) that Branden has seen it work with udhcpc. -- Eric Gillespie * [EMAIL PROTECTED] Software Developer Progeny Linux Systems - http://progeny.com/ When everyone has to reinvent the wheel, many people invent square wheels. - End forwarded message - -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: etherconf only depends on dhcp-client
On Wed, Jul 24, 2002 at 09:01:26AM -0400, Simon Law wrote: Package: etherconf Version: 1.12 Severity: Normal etherconf depends on only dhcp-client, which conflicts with dhcp3-client. This is sad, because only dhcp3-client will work on my system. I suggest the following: Depends: debconf, ifupdown (= 0.6.4), dhcp-client | dhcp3-client, libconfhelper-perl Is this acceptable, or is there some deep down dependency on dhcp-client 2.x? IMO dhcp-client should be a virtual package Provided by dhcp3-client, udhcpc, and pump. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: etherconf only depends on dhcp-client
On Wed, Jul 24, 2002 at 11:36:58AM -0400, Simon Law wrote: On Wed, Jul 24, 2002 at 10:06:34AM -0500, Branden Robinson wrote: IMO dhcp-client should be a virtual package Provided by dhcp3-client, udhcpc, and pump. I also concur. Does that mean that dhcp-client becomes dhcp2-client? No. It just means that it would become a mixed virtual package instead of a pure virtual package, in APT's terminology. Does this not have far reaching effects? It would, if it were necessary. Perhaps Progeny can kludge the etherconf package while I talk to DHCP maintainers? Is this an acceptable compromise? Well, let's see first if there is any disagreement. Adding Provides: to 3 packages should not, in theory, be controversial. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
On Wed, Jul 24, 2002 at 10:20:06AM -0700, Matt Kraai wrote: On Wed, Jul 24, 2002 at 12:53:50PM -0400, Simon Law wrote: What do you guys think? It seems to me that it should be a pretty reasonable thing to push into the next upload. The clients are not interchangable, as they have different interfaces (see #113620). etherconf should depend on an alternative of the clients it supports. Your reasoning is backwards. x-terminal-emulators and mail-tranfer-agents aren't interchangeable either, and have different command line interfaces or configuration file formats. A lot of the time, though, that simply doesn't matter. The correct solution IMO is to have the virtual package and define a baseline set of functionality if necessary. Packages with more specific requirements of a DCHP client can depend only on the clients they support. Packages that require little of, and are truly agnostic about, the DHCP client should not have to enumerate every DHCP client in the distribution in their dependency information. Otherwise everyone who depends on a DHCP client has to rev their package when a new DCHP client is added to the distro. If we handle dhcp-client as we do other virtual packages, the specific knowledge is expressed where it is needed (i.e., my package can use udhcpc and nothing else ), and not everywhere *except* where it's needed. #113620 has little to do with this. ifupdown declares no dependency on any DHCP client. That it did not properly support udhcpc has nothing to do with package dependencies and thus nothing to do with virtual packages. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
On Wed, Jul 24, 2002 at 11:07:02AM -0700, Matt Kraai wrote: [Please excuse my terseness. I'm learning the Dvorak keyboard and this makes me economize my words even more than usual.] So come back to the QWERTY dark side. Quicker, easier. :) If we handle dhcp-client as we do other virtual packages, the specific knowledge is expressed where it is needed (i.e., my package can use udhcpc and nothing else ), and not everywhere *except* where it's needed. This compatibility does not currently exist. udhcpc, for instance, will by default not exit unsuccessfully if it fails to obtain a lease. Other clients use a different option to control this, or do it by default. Similarly for choosing which interface to configure. It's my contention that for the purposes of a virtual package, this simply doesn't matter. postfix, sendmail, and exim exhibit different behaviors as well; that doesn't make them non-mail-transfer-agents. Perhaps you're thinking of alternatives, where command-line compatibility -- at least to some defined extent -- is required. #113620 has little to do with this. ifupdown declares no dependency on any DHCP client. That it did not properly support udhcpc has nothing to do with package dependencies and thus nothing to do with virtual packages. I was citing it as an example of how widely the interfaces differ, not of how the dependencies should be handled. So you have no objection to a dhcp-client virtual package, then? -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
On Wed, Jul 24, 2002 at 11:26:08AM -0700, Matt Kraai wrote: Suppose `Provides: dhcp-client' is added to udhcpc. Does it also need to provide a script, /sbin/dhcp-client, which invokes udhcpc with the correct options, and conflict with the other DHCP clients? Not necessarily, no. A virtual package tells you what the *package* is. It's the job of alternatives to deal with files in the filesystem. I'm not saying there isn't value in having some generic dhcp-client command-line interface that Debian can define; I'm just saying it's not necessary for the specification of a virtual package, and I don't think etherconf needs it, either. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#97671: RFD: Essential packages, /, and /usr
On Sat, Jun 22, 2002 at 09:29:42PM +1000, Anthony Towns wrote: Sorry, but this doesn't follow. Treating serious as a severity or a tag is largely immaterial, and the fundamental point of the serious severity or tag is as an aid to release management. That may be its intent, but apparently that's not how it's being used a large proportion of the time. Branden The Release Manager can strip the release-critical tag off Branden of any bug he wants. This is how things have *always* Branden worked in reality. No, it's not. In reality, things have always just been ignored, rather than being formally stripped of release-criticality. My statement does not assert that the Release Manager has undertaken any formal procedure. I'm saying that it is the case that a bug isn't de facto release critical if the Release Manager doesn't treat it thus. And as much as I'd like to be able to say it's better to have -policy be better and more powerful than the release manager for general democratic and consensus principles, I'm sorry, but it simply hasn't worked, and I'm yet to see *anyone* even remotely interested in making it work. I think these are largely orthogonal issues. Debian Policy is a great tool, but ill-suited to determining release viability for an individual package or for the distribution as a whole. In my opinion and experience, a Debian Policy is better suited to establishing and enforcing objective criteria that ultimately serve to improve the quality of Debian packages, and of the distribution as a whole. Due to the objectivity and specificity of the criteria it establishes, it is easy for a large number of people to participate in the process of crafting Policy in a democratical and consensus-driven manner. Release management is a highly subjective process -- at least the way Debian does it -- because we always settle for something significantly less than perfection (IMO that's a good thing). The establishment of subjective criteria for good enough is often influenced by external factors like upstream releases, security issues, Debian's non-package infrastructure (automated security builds, the mirror network, etc.) and the date on the calendar. Due to that, I think it makes more sense for release management by an individual or a small team of people who work together well. The bottom line for me is that it's difficult to achieve consensus on subjective issues. I think our approach to the twin nemeses of policy and release management need to reflect this fact better than they do at present. -- G. Branden Robinson| Debian GNU/Linux | If encryption is outlawed, only [EMAIL PROTECTED] | outlaws will @goH7Ok=q4fDj]Kz?. http://people.debian.org/~branden/ | pgpV6Xktse9NC.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Thu, Jun 20, 2002 at 11:31:42PM -0400, Clint Adams wrote: Unless policy is changed, indications are that the only packages using command -v by the time of woody+1's release will be XFree86. Easy now. I don't *like* the construction if command -v foo /dev/null 21; then foo fi I hate that nasty redirection that is imposed on me. The only reason I am waiting to change it is because I think there's a good chance a knucklehead POSIX or Policy lawyer is going to keep filing or reopening bugs against my packages no matter what I do.[1] If I change it to use type, one person will complain. If I change it to use which, another person will complain. You won't catch me doing test -x /usr/bin/foo. I refuse to precariously balance my scripts on my confidence that the package maintainer of the package containing foo won't move it to /bin, /sbin, or /usr/sbin. So, although the status quo got a bug filed against my package, I'm sticking with it because the only reasonable alternatives also seem objectionable to one or another of the various POSIX and Policy lawyers in this discussion. If you guys can broker a mutual peace by the time of woody+1's release, you'll likely find me accomodating to the policy you come up with...as long as you don't force me to hard-code paths to other packages' executables. [1] Unlike some folks in this Project, I don't enjoy the privilege of being able to arbitrarily close, reassign, or downgrade actual, valid bug reports against my package. -- G. Branden Robinson| Q: How does a Unix guru have sex? Debian GNU/Linux | A: unzip;strip;touch;finger;mount; [EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck; http://people.debian.org/~branden/ |umount;sleep pgpxUPhIIDQd0.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 02:49:00PM +1000, Anthony Towns wrote: If you can't justify a change without reference to policy, then you shouldn't be suggesting it, !? No more wishlist bugs? -- G. Branden Robinson|I've made up my mind. Don't try to Debian GNU/Linux |confuse me with the facts. [EMAIL PROTECTED] |-- Indiana Senator Earl Landgrebe http://people.debian.org/~branden/ | pgpjTV2tq7fY7.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 03:09:17AM -0400, Clint Adams wrote: I didn't realize that policy compliance was some sort of buddy-boy system. /me watches comprehension slowly, slowly wash over Clint's countenance... -- G. Branden Robinson| It doesn't matter what you are Debian GNU/Linux | doing, emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://people.debian.org/~branden/ | pgpy7wo8IRzzO.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Sat, Jun 22, 2002 at 01:13:47AM +1000, Anthony Towns wrote: Then please, pay attention. I've explained this a dozen times on this list already, so if you need a different wording surely there's someone out there how can provide it. Release critical bugs are _very_ rare. They're not for problems that we're annoyed or embarrased about having, they're not for policy violations in general, they're not for setting goals that need to be done in lots of packages. They are *purely* for those issues which are so severe that they're worth removing packages because of, or saying I'm sorry, we can't release on the day I said, because these issues are unresolved. I had hoped that letting policy have some influence on which policy issues should be considered release-critical would help ensure consistency and a deeper analysis of potential release-critical issues. Instead it seems to be an excuse for people to raise every other policy issue to release-critical status, and I have to either repeatedly argue against it and live with all the mistakes made anyway (like the must idiocy related to /bin/sh). And yes, after eighteen months to two years of having to explain this again and again and again and again -- in spite of it being pretty clearly written in policy itself -- my patience is pretty short on the whole issue. If Mohammed cannot go to the mountain, perhaps the mountain must come to Mohammed. We discussed this on IRC a month or so ago. For the benefit of everyone else here, I'll re-hash it as I remember it. Feel free to correct me if I've misremembered. If: * Release critical bugs are _very_ rare.; and * Release critical bugs should be the domain of the Release Manager, Then we really don't need a tight connection between the serious severity and release-criticality at all. Release-criticality can be a tag -- whether that is expressed in debbugs along with security, moreinfo, patch and so forth or in a webpage like bugscan is immaterial. This tag -- no matter how it is expressed -- is the Release Manager's domain. People can propose that a bug be treated as release-critical and, perhaps, if it seems warranted, we can make this a debbugs tag and possibly automatically set it for all critical, grave, and serious bugs. The Release Manager can strip the release-critical tag off of any bug he wants. This is how things have *always* worked in reality. If a bug is truly a showstopper for a release, we don't release with it. We either wait, fix the bug, or drop the package. I honestly believe this mechanism would head off most of these catfights at the pass. Proper usage of must vs. should in the Policy manual? Immaterial. Mass-filing of serious bugs as public service or masturbatory frenzy? Immaterial. Release-critical? Release Manager's call, period (unless someone bothers to appeal to the Technical Committee -- not a process that is likely to get one a speedy remedy :). And, while we're at it, this would enable us to re-establish a maintainer's discretionary power over bug severities, even serious ones. As Josip Rodin noted in debian-devel, sometimes even a violation of a must directive really isn't a big deal. Sometimes it just doesn't make that much difference. Whether that's due to policy inflating the importance of compliance with a certain detail, or due to unusual circumstances doesn't matter. The Release Manager gets to attach the release-critical tag to any bug he wants, and the package maintainer is expected to act on that bug if he wants his package to release with Debian. If he doesn't, he can alter the severities of his bugs pretty much at his discretion. There is a lot more discussion of this issue in the logs of Bug #97671. http://bugs.debian.org/97671 N.B.: the above is my recollection of a conversation, and should not be construed as representing the opinions of anyone else unless they say so. -- G. Branden Robinson|I've made up my mind. Don't try to Debian GNU/Linux |confuse me with the facts. [EMAIL PROTECTED] |-- Indiana Senator Earl Landgrebe http://people.debian.org/~branden/ | pgpOAqBhELoIR.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 01:00:25AM -0400, Clint Adams wrote: This depends on the user's perspective. I can't imagine ever wanting to do anything other than 'test -x /absolute/path' in a postinst. I can. I just want to know if the command is available for my script to use; I don't care about the latest flamewar that moved it in or out of /usr or */sbin. -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | pgpXl4ubDG2uE.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 05:14:23AM -0400, Clint Adams wrote:
Apparently if you have zsh as /bin/sh and try to install xdm, the
postinst will happily tell you what version of debianutils to install to
get readlink.
?
First I've heard of this. What's going on?
Oh, I know.
if ! command -v readlink /dev/null 21; then
message The readlink command was not found. Please install version \
1.13.1 or later of the debianutils package.
readlink () {
# returns what symlink in $1 actually points to
perl -e '$l = shift; exit 1 unless -l $l; $r = readlink $l; exit 1 unless
$r; print $r\n' $1;
}
fi
Yeah, well, I'll be happy to change this once we have some official
Policy, or an offical Best Current Practice statement.
I'll let the shell maintainers finish their penis war first, though.
--
G. Branden Robinson| You live and learn.
Debian GNU/Linux | Or you don't live long.
[EMAIL PROTECTED] | -- Robert Heinlein
http://people.debian.org/~branden/ |
pgpfb0d7RsD09.pgp
Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Sun, Jun 16, 2002 at 10:00:31PM -0500, Manoj Srivastava wrote:
Branden A list of criteria other than just run for F in $(grep-available -F
Branden Essential -s Package yes | awk '{print $2}'); do dpkg -L $F | egrep
Branden '^/s?bin/.'; done, that is.
Sounds like a fine criteria to me. Any particular reason this
is not good enough?
It changes over time. Additions are arguably not a problem at all;
removals can be.
I'd *still* rather see us *document* our collective wisdom with respect
to what minimal means.
Is anybody particularly cheesed off that Decklin Foster put nc in /bin?
If not, what rules of thumb should we be using? Obviously the X server
falls on the other side of the line. Where is the line?
Oh, incidentally, this raises an auxiliary point. netcat isn't
Essential. At present, it's not even standard. An early-running init
script can have its package Depend on netcat, but until Decklin moved nc
to /bin, the init script *still* wouldn't work.
Therefore, I think we really do have two separate issues here.
Essentiality and /usrness. This points up the even greater need for a
definition of a minimal system.
--
G. Branden Robinson|There is no housing shortage in
Debian GNU/Linux |Lincoln today -- just a rumor that
[EMAIL PROTECTED] |is put about by people who have
http://people.debian.org/~branden/ |nowhere to live.-- G. L. Murfin
pgpgEuQPVLClJ.pgp
Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Mon, Jun 17, 2002 at 01:07:23PM +1000, Herbert Xu wrote: Branden Robinson [EMAIL PROTECTED] wrote: Further, /bin/bash is available and provides both type and test as builtins. Bad news for any Debian port that wants to use ash as its Essential shell, then. I hate to break it to you but all the shells that could potentially serve as /bin/sh in Debian provide type and test as builtins. That includes ash. And which(1)? -- G. Branden Robinson|It was a typical net.exercise -- a Debian GNU/Linux |screaming mob pounding on a greasy [EMAIL PROTECTED] |spot on the pavement, where used to http://people.debian.org/~branden/ |lie the carcass of a dead horse. pgpxK7HWLatMR.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Sun, Jun 16, 2002 at 03:16:12PM +1000, Anthony Towns wrote: On Thu, Jun 13, 2002 at 01:17:45PM -0500, Branden Robinson wrote: So why waste everyone's time discussing it rather than just using sed or /bin/sh and getting on with your life? Because this isn't just about me, and it isn't just about cut(1).[1] cut was what was brought up. Do you really care about ddate being in /bin rather than /usr/bin? No. Is it your position that every executable from an Essential package that isn't already in /sbin or /sbin is as frivolous as ddate? If not, why imply it? It's about what authors of early-running init scripts in general can expect to have at their disposal. They can expect to have what they absolutely need, and pretty much nothing else. So, rather than establishing any guidelines for what they're going to absolutely need, we'll just tell them that what they absolutely need is whatever happens to be in /bin or /sbin today. If there's something cut can do that sed can't that's absolutely needed by an init script that needs to run before /usr's mounted it'd be reasonable to move it. If it's just a nuisance to have to learn a different tool, well, that's not a reason to move cut. s/cut/$anything/ And if the package maintainer disagrees? The set of files provided by Debian's Essential packages is, in fact, minimal. Depends what you mean. Yup. So what *does* Debian mean? Interesting that you didn't bother to propose an answer to this. I infer that what Debian means is whatever is in /bin or /sbin today, which can change. The items listed above are ones that generally need to be in essential packages. Particularly perl, sort, tr and kin. That is to say, they need to be available for the Debian packaging tools to function. That's the definition of an Essential package, not the definition of a minimal Debian system. Are all of the above necessary for minimal operations? Certainly not. But they don't need to be available to mount /usr. Whether they're needed for minimal operations depends on which of those options you're referring to. What options are we willing to support in our minimal system? Shall we just leave this undefined and say, well, whatever you can manage to accomplish with whatever happens to be in /bin or /sbin today? If they're not in /usr, they're off-limits. As are the POSIX utilities for determining whether or not they're in /usr. And the burden of proof lies on you to demonstrate why you absolutely must have any particular one available beforehand. Translation: the intersection of all Essential package maintainers' opinions shall determine what will be possible before /usr is mounted. Given that test and which are extremely useful for figuring out what's on the system for control flow purposes, If you're running before /usr's mounted, you're using stuff from /bin or /sbin, so there's not a huge amount of benefit to being able to figure out where you're running from. Where I'm running from? I was unaware that test(1)'s utility was so limited. Further, /bin/bash is available and provides both type and test as builtins. Bad news for any Debian port that wants to use ash as its Essential shell, then. OH NO! THERE'S _NO OFFICIAL LIST_!!! THEREFORE EVERYTHING I SAY MUST BE WRONG OH WOE IS ME!! We have neither a list nor a set of guidelines documented anywhere as to what the maintainer of an early-running init script can expect to accomplish. Instead, he has to experiment, and do one of several things when his experiments fail: 1) give up 2) plead with the maintainer of an Essential package to accomodate him 3) rewrite his init script to use different utilities 4) rewrite his init script in perl 5) compile his init script as an ELF executable Why do you find it so abhorrent to document the assumptions we are making about the system before /usr is mounted? What is the utility of a clubhouse mentality in the root partition? What can early-running init scripts, not to mention sysadmins ACTUALLY TRYING TO RECOVER A SYSTEM, rely upon to be present? Depends how badly your system's screwed. In some cases you can't rely on anything working (libc6 is screwed, sash isn't installed, the kernel got corrupted, you have a hardware failure...). Of course. Not only are you arguing for a very low threshold above which the root partition is totally useless (i.e., many failure scenarios render the system unbootable to a multi-user runlevel) and thus increasing the need for a rescue disk, you're arguing that we shouldn't even be telling people what informs our reasoning why the bar is set where it is. For instance, netcat recently moved its executable (nc) from /usr/bin to /bin. If another Debian developer disagrees with that, on what grounds would he object? Does he have a leg to stand on? Surely there must *some* criteria we apply to keep things out of the root partition. (For the record, I don't
Re: RFD: Essential packages, /, and /usr
On Sun, Jun 16, 2002 at 12:55:32PM -0500, Manoj Srivastava wrote:
Nice polemics. But each side here has a modicum of logic on
their side; Branden wants a nice, uncontroversial, black and white,
writ in stone (well, may be not) list of commands available to
maintainers of packages that appear early in the boot process, when
parts of the standard system may not be populated. Merely looking at
whether the package is Essential is not enough; since /usr is not
mounted early in the boot process.
You are oversimplifying my argument.
I did not ask solely for a list of commands. Alternatively, I asked for
a list of criteria that are determinative of what sorts of tools Debian
puts in /sbin and /bin as opposed to /usr.
A list of criteria other than just run for F in $(grep-available -F
Essential -s Package yes | awk '{print $2}'); do dpkg -L $F | egrep
'^/s?bin/.'; done, that is.
The pro is obvious, one can then figure out easier how to
package something like that, and perhaps even allocate fault in some
packages with no argument whatsoever. The Con is that this list has
to be maintained, and may be superfluous, and seems to be designed
to be yet-another-stick-to-beat-recalcitrant-developers-with.
Straw man, as you are fond of saying. Given that no one has designed it
yet, how can you make assumptions about their motivations? Presumably,
were Anthony compelled to create such a list, he'd grant quite a bit of
latitude.
(Superfluous how? just look at the cvontents of /bin and /sbin to
determine whether to command is actually available that early in
boot).
Just run for F in $(grep-available -F
Essential -s Package yes | awk '{print $2}'); do dpkg -L $F | egrep
'^/s?bin/.'; done.
Aj, on the other hand, is logically asking for continuing to
use package priority
I thought he was asking that we use package essentiality, though I
suppose one could argue that essential is a virtual priority, one
higher than any others.
Alternatively, my grep-available command needs to be changed.
and content of /bin and /usr as a guide, and
asking for logical, and technically convincing reasons for changing
the setup, and using these to obviate the need for the list. The con
here is that since we are allowing people a modicum of free will,
there shall be controversy.
The con is that a position analogous to library documentation saying
the API is whatever happens to be in the header files today needs to
be explicitly justified.
As to the specifics of cut; I do not find any argument advanced
so far that is convincing; I still think that a minimal / is a
desired goal.
I've long since granted that cut is not an interesting example, at least
not the way I was using it.
If you're up to it, however, I would like to challenge you to implement
/usr/bin/tr(1) in /bin/sed(1). I few of us on IRC tried several days
ago to do it, and concluded that it couldn't be done.
Of course, we can all admit we are wrong, Jeroen was write,
and like the Hurd, do away with the silly /usr thang for once and for
all.
I presume this is facetious because A) you mentioned Jeroen ;-) and B)
the Hurd's union mounts don't get you around the problem that / will
have more or less in it depending on how early in the boot sequence you
are. (At least, as I understand the Hurd, which is not very well.)
--
G. Branden Robinson|It's like I have a shotgun in my
Debian GNU/Linux |mouth, I've got my finger on the
[EMAIL PROTECTED] |trigger, and I like the taste of
http://people.debian.org/~branden/ |the gunmetal. -- Robert Downey, Jr.
pgpwRv8ODieJy.pgp
Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Sun, Jun 16, 2002 at 11:37:40PM +0100, Stephen Stafford wrote: | On Sun, Jun 16, 2002 at 03:13:23PM -0500, Branden Robinson wrote: | If you're up to it, however, I would like to challenge you to implement | /usr/bin/tr(1) in /bin/sed(1). I few of us on IRC tried several days | ago to do it, and concluded that it couldn't be done. [...] stephen:~$ echo ABC | sed 'y/ABCD/abcd/' abc Sure it does. It just has different syntax :) If I recall correctly, I was trying to do something with POSIX character classes. N.B.: This has nothing to do with discover's init script. -- G. Branden Robinson| No math genius, eh? Then perhaps Debian GNU/Linux | you could explain to me where you [EMAIL PROTECTED] | got these... PENROSE TILES! http://people.debian.org/~branden/ | -- Stephen R. Notley pgpZO0Gywpaqz.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Thu, Jun 13, 2002 at 11:20:31PM +1000, Anthony Towns wrote: On Tue, Jun 11, 2002 at 12:35:27PM -0500, Branden Robinson wrote: On Fri, Jun 07, 2002 at 02:55:23PM +1000, Herbert Xu wrote: Anyway, there are already plenty of tools in /bin capable of performing the task of cut(1). Sure. So why waste everyone's time discussing it rather than just using sed or /bin/sh and getting on with your life? Because this isn't just about me, and it isn't just about cut(1).[1] It's about what authors of early-running init scripts in general can expect to have at their disposal. Your answer is apparently whatever happens to be in /sbin and /bin and that's it. What if that changes? See the bug logs of #149256 for more information. Here, I'll give you a link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149256repeatmerged=yes The set of files provided by Debian's Essential packages is, in fact, minimal. Depends what you mean. Yup. So what *does* Debian mean? ddate, dpkg, dselect, factor, find, mawk, perl, sort, tr, tsort, uniq, update-rc.d, whoami, xargs, and yes are all in essential packages and in /usr/bin. As are logger, renice, replay, script, wall, savelog, sensible-editor, sensible-pager, which (!), mkboot, cmp, diff, diff3, sdiff, dpkg-deb, dpkg-split, md5sum, chattr, lsattr (hmm, good luck troubleshooting a problem with a bad ext2 attribute flag to recover a system), uuidgen, mklost+found, dircolors, du, install, link, mkfifo, shred, unlink, rgrep, clear, infocmp, tack, tic, toe, tput, tset, basename, dirname, env, expr, id, logname, patchchk, printenv, printf, seq, tee, test (!), tty, whoami, hostid, nice, pinky, users, who, groups, nohup, [, chroot, rmt, cksum, comm, csplit, cut, expand, fmt, fold, head, join, nl, od, paste, pr, ptx, split, sum, tac, tail, unexpand, wc, md5sum.textutils, chkdupexe, fdformat, getopt, ipcrm, ipcs, mcookie, namei, rev, setsid, setterm, whereis, cytune, elvtune, readprofile, and tunelp. Are all of the above necessary for minimal operations? Certainly not. Should every single one of these be off-limits to early-running init scripts and people attempting to recover their systems? I don't think so. Given that test and which are extremely useful for figuring out what's on the system for control flow purposes, I'm amazed that someone would argue that they are inessentials tools. Actually I'm not amazed; I've grown quite accustomed to the argument that Debian developers should eat what they're fed and like it, or at least keep their mouths shut about it. Essential packages are the ones needed to maintain a Debian system; utilities in /bin and /sbin are ones needed to recover a system. Okay, great. Where's our official list of utilities needed to recover a system. What can early-running init scripts, not to mention sysadmins ACTUALLY TRYING TO RECOVER A SYSTEM, rely upon to be present? If we expect admins to have a rescue disk available (trying to recover a Debian system with only /sbin and /bin? Don't do that, then.), then your assertion about what's minimal is a red herring. We would not, in fact, actually expect /bin and /sbin to be used for this purpose. Are you suggesting that we substitute your judgement of what is minimal for the Debian Policy Manual's? People like Herbert's judgement is what was used to write the policy manual. I hate to break it to you, but I'm the author of several accepted policy proposals as well. If you feel my judgement is categorically suspect, you should propose the repeal of all the amendments I've authored. I'm CCing debian-policy as a means of RFD. I invite your participation if you have something to contribute beyond don't do that, then. Sometimes so don't do that, then is the right answer. See above. All I hear from you are arguments for the status quo, and the divine right of Essential package maintainers to put their executables wherever they want, with no accountability to anyone. Let's not have any critera for establishing what's minimal, and let's certainly not have a list that would hamper Essential package maintainer's discretion to act as they please. No. Maintainers of Essential packages have a *greater* responsibility to Debian developers and Debian users, *because* their packages are always installed, and their functionality is fundamental. We must hold these packages to higher standards than those which we apply to the ICQ client of the week in extra. Note: a simple list of the Essential package executables of /bin and /sbin from the woody release, presented as a policy proposal, is a perfectly legitimate response to my complaints. However, I'm not going to be the one making that proposal because I feel that there are several things which should be in /bin or /sbin that currently aren't. Someone reading this list who believes firmly in the status quo should make that proposal instead. Given the tone of your reply, Anthony, that means you. [1
RFD: Essential packages, /, and /usr
On Fri, Jun 07, 2002 at 02:55:23PM +1000, Herbert Xu wrote: Anyway, there are already plenty of tools in /bin capable of performing the task of cut(1). Sure. I could also write a C program to accomplish the task, and ship it with my package. Then we'd get useless bloat, especially if other people followed my example. If Essential tools are in / where people's init scripts can rely on their existence, everybody wins. The root partition is meant to be minimal. Yes. The set of files provided by Debian's Essential packages is, in fact, minimal. Are you suggesting that we substitute your judgement of what is minimal for the Debian Policy Manual's? So I don't see any point of moving cut there when its functionality is there in the form of sed and awk (not to mention the shell itself). Actually, you're wrong about that: /usr/bin/awk /usr/bin/gawk /usr/bin/mawk Amusingly, even the tool we tell people to use so that they don't have to hard-code absolute paths to executables is not available before /usr is mounted: /usr/bin/which ...so people can't even use which in their early-running init scripts to determine whether the executables they need exist. Of course, I'm sure you're already aware of this, as you are of http://lists.debian.org/debian-devel/2002/debian-devel-200205/msg02540.html. I'm CCing debian-policy as a means of RFD. I invite your participation if you have something to contribute beyond don't do that, then. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#149709: [BUG] section 10.3.3 does not provide enough guidance for package maintainers to use update-rc.d correctly
Package: debian-policy Version: 3.5.6.1 Severity: normal A couple of points regarding policy 10.3.3 (Managing the links): 1) The policy does not mention that if your package changes its runlevels or priority, that update-rc.d package remove MUST be called, or update-rc.d will leave the existing links in place. Given that many other tools named update-* in Debian don't work this way, it might be advisable for the examples in Policy to mention this. 2) The examples advise people to redirect the output of update-rc.d to /dev/null. Adam Heath and I feel this is a bad idea, and even if this change is not made, some people (like the author of lintian; see Bug #149700) think that this is normative. To me the example looks informative, not normative, as it would be inappropriate to put the example text into an ELF maintainer script or a perl script. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux zuul.progeny.com 2.4.18-386 #2 Sun Apr 14 10:38:08 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages debian-policy depends on: ii fileutils 4.1-10 GNU file management utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: command -v in postinsts violating policy
On Sun, May 26, 2002 at 09:31:36AM +0200, Luca - De Whiskey's - De Vitis wrote: Hi Branden, do you mind if i start working on your packages to replace any occurrence of the 'command -v' with any other alternative good solution? Yes, I mind a great deal. I am not soliciting patches to correct this problem, and don't even think about NMUing packages. So far, no one has proposed a standards-compliant way of solving the problem that retains command -v's robustness. I'm sure that policy rocks, and that task may be accomplished be any developer, so the only way i can demonstrate it is doing. Let me be perfectly clear: KEEP YOUR HANDS OFF OF XFREE86. -- G. Branden Robinson|Somewhere, there is a .sig so funny Debian GNU/Linux |that reading it will cause an [EMAIL PROTECTED] |aneurysm. This is not that .sig. http://people.debian.org/~branden/ | pgpjAJGIBfCy8.pgp Description: PGP signature
Re: command -v in postinsts violating policy
On Sun, May 26, 2002 at 11:58:49PM +0200, Luca - De Whiskey's - De Vitis wrote: I'm only sorry that the election period is over: you were quite friendly. I'm still friendly to people who aren't doing things deserving of an unfriendly response. Offering to hijack 600 packages so their maintainer scripts can be made less robust is quite deserving of an unfriendly response. -- G. Branden Robinson| The only way to get rid of a Debian GNU/Linux | temptation is to yield to it. [EMAIL PROTECTED] | -- Oscar Wilde http://people.debian.org/~branden/ | pgpZX1fUsMn6n.pgp Description: PGP signature
Re: command -v in postinsts violating policy
On Sun, May 26, 2002 at 11:46:40PM +0200, Josip Rodin wrote: On Sun, May 26, 2002 at 04:06:29PM -0500, Branden Robinson wrote: Let me be perfectly clear: KEEP YOUR HANDS OFF OF XFREE86. You do realize this is now going to be quoted out of context and used in all sorts of ad hominem attacks? :) Oh, you mean like every other thing I say? What else is new? :-P -- G. Branden Robinson| Debian GNU/Linux | Ab abusu ad usum non valet [EMAIL PROTECTED] | consequentia. http://people.debian.org/~branden/ | pgp4QWVdHQCJF.pgp Description: PGP signature
Re: command -v in postinsts violating policy
On Sat, May 25, 2002 at 03:42:40PM -0400, Clint Adams wrote: Below is a list of packages that may use 'command -v' in their #!/bin/sh postinsts. Section 11.4 of Policy states that /bin/sh can be a symlink to any POSIX-compatible shell, with an exception for 'echo', and that package #!/bin/sh scripts must not use non-POSIX features. Since there is no 'command' binary in a package marked Essential, the use of 'command -v' is a policy violation. Other than ignoring this problem, solutions include [...] 2) Amending policy with another /bin/sh exception. That's my preference. Of course, I am hardly unbiased as I pretty consistently and deliberately use command -v in my maintainer scripts. -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | pgp8sDsu6aF53.pgp Description: PGP signature
Re: command -v in postinsts violating policy
On Sat, May 25, 2002 at 11:19:02PM +0200, Luca - De Whiskey's - De Vitis wrote: Change the rules for all the Debian distribution because you find that 'command -v' is handy, seems quite excessive to me... You need to stop hitting the hooch and start thinking more about what Debian is trying to accomplish. Over six hundred packages already use it, it prevents the hard-coding of paths into maintainer scripts and thus renders them more robust against harmless changes in other packages (e.g., moving traceroute from /usr/sbin to /usr/bin) and is otherwise useful. I am far from the only package maintainer who employs this tool. -- G. Branden Robinson| I came, I saw, she conquered. Debian GNU/Linux | The original Latin seems to have [EMAIL PROTECTED] | been garbled. http://people.debian.org/~branden/ | -- Robert Heinlein pgpIRzuTDXezl.pgp Description: PGP signature
Re: command -v in postinsts violating policy
On Sat, May 25, 2002 at 07:22:17PM -0400, Clint Adams wrote: the problem is there is no better replacement for 'command -v'. And we do not really need an exception -- every shell we have supports this. So the only way Well, that's not true. As Luca has pointed out, /usr/bin/which is Essential at the moment. Also, not every shell in Debian supports `command -v', as was pointed out. If zsh does not attempt to provide /bin/sh, though, this is not a problem in practice. Meaning that we don't have to hold up the woody release over it or anything. We should still pick a path forward for woody + 1. IMO, anyone who uses zsh for /bin/sh is quite insane. ;-) -- G. Branden Robinson| Suffer before God and ye shall be Debian GNU/Linux | redeemed. God loves us, so He [EMAIL PROTECTED] | makes us suffer Christianity. http://people.debian.org/~branden/ | -- Aaron Dunsmore pgpFWFAP2HT4K.pgp Description: PGP signature
Re: command -v in postinsts violating policy
On Sat, May 25, 2002 at 07:46:07PM -0400, Clint Adams wrote: IMO, anyone who uses zsh for /bin/sh is quite insane. ;-) Perhaps, but it's been done. Does Debian explicitly support such a configuration? That's the point. I can symlink /bin/sh to /usr/bin/tcsh or /usr/bin/X11/XFree86 if I want, but that doesn't mean that the Debian packaging infrastructure offers to it for me via a debconf question, update-alternatives, or some similar mechanism. -- G. Branden Robinson| The noble soul has reverence for Debian GNU/Linux | itself. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | pgptpJQDB52Yh.pgp Description: PGP signature
Re: command -v in postinsts violating policy
[You guys sure do appear to love private CCs...] On Sat, May 25, 2002 at 10:59:50PM -0400, Clint Adams wrote: I have nothing against policy-compliant scripts. But why blessing a lie in policy is the option preferred by anyone is a mystery to me. No one is advocating such a position. It is a hallucination of your fevered mind. -- G. Branden Robinson|There is no housing shortage in Debian GNU/Linux |Lincoln today -- just a rumor that [EMAIL PROTECTED] |is put about by people who have http://people.debian.org/~branden/ |nowhere to live.-- G. L. Murfin pgpR5DZ2opxwB.pgp Description: PGP signature
Re: The Serious severity
go 03:33AM|Overfiend I would like to have serious-policy-violations represented by a tag, because of criterion 3) 03:33AM|aj policy violations can have a tag if he insists, but i've been planning on ripping the serious - must thing out for ages anyway. i have to repeat the no, it's not like the RFC's argument waay to often. you saw iwj come up with it again just recently, right? 03:34AM|Overfiend aj: yes 03:34AM|Overfiend 03:32AM|aj surely the release manager tagging something unreleasable then saying oh, but it'll release anyway would be even more annoying? 03:34AM|Overfiend Re: that, I don't think so 03:34AM|aj nwp_: it happens ocassionally. what'll be truly remarkable if we start out disagreeing and move to agreement *without* the horrific flamewar in between 03:34AM|Overfiend if unreleasable is the RM's pissing ground, then people can be expected to guess what it means if the package releases anyway 03:34AM|Overfiend ideally we'd have a gizmo that auto-retagged them, but that's cosmetic 03:35AM|Overfiend and ideally it would hook into bugscan, etc. 03:35AM|aj hrm 03:35AM|nwp_ heh... well, good to see anyway. It's *so* fucking frustrating watching you guys violently agree with each other when you both want the same thing really ;) 03:35AM|Overfiend in my conception, I as maintainer could tag a bug as unreleasable if I felt it needed the RM's attention 03:36AM|Overfiend i.e., Gosh, this bug is pretty sucky, what do you think/ 03:36AM|aj that's the problem with tags, they'll probably tend to have to be added after the fact, which is much harder to do than removing/downgrading after the fact 03:36AM|Overfiend but the RM's decision is final if he removed the tag, barring further information 03:36AM|aj Overfiend: as a maintainer you get to declare your packages unreleasable for whatever reason you choose 03:36AM|Overfiend oh, really? 03:36AM|Overfiend okay, that leaves a role for serious, then 03:36AM|aj Overfiend: check the second half of the serious def'n 03:36AM|Overfiend as a severity 03:36AM|Overfiend yes 03:36AM|Overfiend I wasn't sure you wanted to try eliminating serious or not 03:37AM|ilm would /usr/share/texmf/tex/latex/java2latex/ be a good place? the package uses /usr/TeX/inputs/ 03:37AM|aj (i made up serious, all the stuff it covers is meant to be that way and works fairly well to a first approximation) 03:38AM|Overfiend aj: I'd like to avoid a retread of the current flamewar by defining domains of authority. the serious severity is for the maintainer, the unreleasable tag would be for the RM, and serious-policy-violation or whatever would be for the Policy czars 03:39AM|Overfiend that way, whether the RM chooses to respect a given critical/grave/serious bug as truly RC would be up to him 03:39AM|Overfiend IOW I could say oh my God, it would humiliate me if XFree86 shipped this way, severity 12345 serious . tag 12345 unreleaseable, but the release manager can remove that tag and say tough, it's shipping 03:40AM|Overfiend aj: is this consistent with what you understood our consensus to be? 03:40AM|Overfiend and whatever the policy manual says is actually decoupled from BOTH of these concerns 03:42AM|Overfiend oh darn, did I lose him? 03:44AM|*W* aj is aj@azure.humbug.org.au (Anthony Towns) 03:44AM|*W* On channel #debian-devel 03:44AM|*W* On IRC via server irc.openprojects.net (http://www.openprojects.net/) 03:44AM|*W* aj has been idle for 6:42; on since Wed Apr 24 00:43:12 2002. 03:44AM|Overfiend 03:44AM|*W* aj has been idle for 6:42; on since Wed Apr 24 00:43:12 2002. 03:44AM|Overfiend yup, I think I lost him :) 03:44AM|Overfiend oh well 03:44AM|* Overfiend archives this so he doesn't forget it -- G. Branden Robinson| Convictions are more dangerous Debian GNU/Linux | enemies of truth than lies. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | pgpWRRm47K08K.pgp Description: PGP signature
Re: The Serious severity
On Thu, May 02, 2002 at 03:10:34PM -0500, Manoj Srivastava wrote: Strawman. ? I don't see how. The rationale I presented argues for creating a severity to use for violations of policy. The point was to allow for violations of must directives to be flagged as problems in themselves, potentially release critical, thereby acknowledging the importance of Debian policy for packages (IMHO policy is the major difference between the solidity of a Debian machine vs other distributions). The same function can be served by a tag, as the IRC discussion illustrates. Branden Since you want to drag this out in the public forum of debian-policy, Branden I'll post some relevant hunks of IRC log. Talk about hypocrisy. This is the same person who ranted about lack of transparecy when he was not in the innner circle, but has a problem with the DPL, RM, and a DPL candidate discussing a corner stone of Debian like the BTS being dragged into the light of day. Talk about leaping to conclusions. I was simply waiting to come forward with talk of a consensus between Anothony and myself until he had signed off on it, so that I could be sure I wasn't misrepresenting his position. I am attaching the mail I sent him, so please feel free to go ahead and accuse me of forging the Date: header before digitally signing it. Pardon me for trying to bring the people who do not IRC into the conversation. Pardon me for attempting to be courteous to Anthony by not speaking for him. And, for the sake of openness and transparency: 03:38PM|* Manoj goes off to bait Overfiend on the policy list 03:39PM|Manoj serves him right for discussing serious severity minutes after I signed off to go to bed I don't see how that attitude helps anyone. Surely people do not need your permission to discuss the utility of the serious severity? -- G. Branden Robinson|If a man ate a pound of pasta and a Debian GNU/Linux |pound of antipasto, would they [EMAIL PROTECTED] |cancel out, leaving him still http://people.debian.org/~branden/ |hungry? -- Scott Adams From [EMAIL PROTECTED] Thu May 2 03:54:25 2002 Date: Thu, 2 May 2002 03:54:25 -0500 From: Branden Robinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Anthony and Branden's consensus Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=N7HXVILz59yg1nI8 Content-Disposition: inline User-Agent: Mutt/1.3.28i Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Status: RO Content-Length: 10227 Lines: 199 --N7HXVILz59yg1nI8 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Any comments on this? I'll put it into digestible form tomorrow, mail you again to make sure I don't screw it up, and then pass along the resulting document to the -ctte. 02:53AM|Overfiend I still do not see what harm would be done by shifting = the first half of the serious severity definition to a tag 02:53AM|Overfiend certainly no automated tools would be adversely affecte= d, aside from having to account for the change. 02:53AM|bdale Overfiend: so, propose doing so after woody releases 02:53AM|Overfiend bdale: where did I propose doing so before it releases? 02:53AM|nwp_ IMHO the bugscan overrides are logically equivalent to such = a tag, but less transparent. 02:54AM|* Shadur curses once more the S3 Savage series 02:54AM|bdale Overfiend: rephrase. so, shut up about it until woody rele= ases. 02:54AM|Overfiend nwp: ooh, transparency, once of my hobby-horses, as iwj= would put it 02:54AM|aj Overfiend: what harm would come of you calling yourself Dubbl= ebub from now on? Not really any, it'd just be a nusiance while people got= used to the new description. That isn't really the question, the real question is what's the benefit. 02:54AM|Overfiend bdale: if people keep dialoguing with me about it, I'll= keep answering them. 02:55AM|bdale Overfiend: yes, I'm painfully aware of that. 02:55AM|bdale oh well, I still get more spam emails per day than OF email= s, so it's not really a problem. :-) 02:56AM|aj Overfiend: it would've been much better to have done the [IGNO= RE] stuff from a month or two ago, it would probably have been good to have= [IGNORE] put in the BTS rather than in ~wakkerma/bugscan/comments on master, but those aren't going t= o be fixed for woody (because no one but me is going to do anything about t= hem; and i don't have the time to do them) 02:56AM|Overfiend aj: the benefit is that 1) package maintainers get to p= reserve the pre-serious utility of their bug list as a triage tool; 2) the = release manager gets to discern violation of musts/requireds in policy 3) perhaps, the policy team h= as an easier time of discerning compliance
Bug#139957: period at the end of short description?
On Wed, Mar 27, 2002 at 10:51:24PM -0500, Colin Walters wrote: Branden, do you have an argument for why capitalization should be discouraged? We went over this in the list archives the last time the issue came up and Manoj planted his feet. My reasons are two: 1) I think it's bad style to capitalize something that isn't a title or a sentence. 2) It's possible to give the ucfirst and period at end crowd what they want via a package browsing interface. You just manipulate the package description string that you are given. The reverse transformation is not reliably possible. Consider the following hypothetical package description: Description: GNOME-based game; you're an ambulance driver and you've got to keep your patients from arriving at the hospital D.O.A. Now, needless to say, the above example is way too long, but you get the idea. Would you want this to end up as: Description: gNOME-based game; you're an ambulance driver and you've got to keep your patients from arriving at the hospital D.O.A? The leading mandatory capital letter and trailing period are noise, not signal. Thus, they should be added where noise isn't a problem. -- G. Branden Robinson| Communism is just one step on the Debian GNU/Linux | long road from capitalism to [EMAIL PROTECTED] | capitalism. http://people.debian.org/~branden/ | -- Russian saying pgpgPZ6jnDmBb.pgp Description: PGP signature
Bug#139957: period at the end of short description?
On Wed, Mar 27, 2002 at 11:58:48AM -0600, Manoj Srivastava wrote: Anthony IMO, what policy is is a means of recording the current Anthony consensus on packaging issues amongst developers. It's Anthony necessary to have that written down somewhere rather than in Anthony everyone's heads, since there's so much of it and it's too Anthony easy to forget. Nearly 20% of the packages do not conform to this so called consensus. Ah, so over 80% do. If that's not a consensus, then my grounds for fearing that you will attempt to impose some sort of insanely high supermajority requirement upon amendment of the Social Contract or DFSG are, perhaps, not so ill-founded. Even a 4:1 supermajority is too low. Amazing. -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | pgpLfY0lkWcbU.pgp Description: PGP signature
Bug#139957: period at the end of short description?
On Tue, Mar 26, 2002 at 01:10:14AM -0500, Colin Walters wrote: cd /tmp/ diff -u -L /usr/share/doc/debian-policy/policy.sgml.gz -L /tmp/policy.sgml.new /tmp/jka-com6962AcG /tmp/policy.sgml.new --- /usr/share/doc/debian-policy/policy.sgml.gz +++ /tmp/policy.sgml.new @@ -2397,7 +2397,9 @@ p The single line synopsis should be kept brief - certainly - under 80 characters. + under 80 characters. This should be a sentence fragment + which summarizes the key features provided by the package. + It should not end in a full stop (`.'). /p p I second this. We should also discourage capitalization of the first letter in a package description. (I.e., don't make it a capital letter if it wouldn't be one in the middle of a sentence.) -- G. Branden Robinson| Never attribute to malice that Debian GNU/Linux | which can be adequately explained [EMAIL PROTECTED] | by stupidity. http://people.debian.org/~branden/ | pgpH4QjJI4nE3.pgp Description: PGP signature
Re: Adding debian/rules unpack as a required operation
On Thu, Jan 17, 2002 at 04:03:32PM -0600, Manoj Srivastava wrote: David == David Starner [EMAIL PROTECTED] writes: David A suggestion for policy: David If a package source does not come fully unpacked - i.e. it uses a David DBS-like system - debian/rules must include an unpack target, that David unpacks the source code and applies all patches to it. Umm. I suggest you talk to the people who are using DBS (and perhaps also talk to Adam Heath, the author, to include suggestions in the DBS docs) to implement such a target. Policy is not a stick to beat people on the head with. While I agree with you vis a vis Policy, I have no objection to such a thing, speaking as the maintainer of a very large, DBS-using package. -- G. Branden Robinson|Build a fire for a man, and he'll Debian GNU/Linux |be warm for a day. Set a man on [EMAIL PROTECTED] |fire, and he'll be warm for the http://people.debian.org/~branden/ |rest of his life. - Terry Pratchett pgpp0lMD17cP1.pgp Description: PGP signature
Bug#122931: debian-policy: Spelling consistency depend(e|a)ncies in policy 2.3.8.1
On Sun, Dec 09, 2001 at 11:43:05PM -0500, John R. Daily wrote: As largely irrelevant data points, my 1955 edition of the Oxford Universal, the 2nd edition of the Random House unabridged, Webster's 3rd New International, and the 1952 New Century dictionaries concur that dependancy is legitimate. Webster's 2nd edition New International does not recognize it. What's the date on the latter dictionary? I'm willing to bet most modern lexicographers have adopted the quite sensible rule-of-thumb that no spelling based on a French etymology should be accepted when a Latin one is available instead. (/me casts his line and waits for a bite) -- G. Branden Robinson| When I die I want to go peacefully Debian GNU/Linux | in my sleep like my ol' Grand [EMAIL PROTECTED] | Dad...not screaming in terror like http://people.debian.org/~branden/ | his passengers. pgpggGQ4zDpYS.pgp Description: PGP signature
Re: Bug#122817: base-files: Please provide profile.d hook in /etc/profile
On Mon, Dec 10, 2001 at 11:11:06AM +0100, Javier Fernández-Sanguino Peña wrote: On Fri, Dec 07, 2001 at 09:37:37AM -0500, Branden Robinson wrote: On Fri, Dec 07, 2001 at 03:04:39PM +0100, Javier Fernández-Sanguino Peña wrote: You are wrong here. Sample: - I want to provide a package with a lot of useful bash functions/aliases w/o changing any program Write scripts and put them in /usr/local/bin. ¿? Packages cannot place scripts in /usr/local/bin. It's against policy. A package YOU make, used only on your own system, doesn't have to follow Debian Policy. -- G. Branden Robinson|If a man ate a pound of pasta and a Debian GNU/Linux |pound of antipasto, would they [EMAIL PROTECTED] |cancel out, leaving him still http://people.debian.org/~branden/ |hungry? -- Scott Adams pgplWY2sYzdWC.pgp Description: PGP signature
Bug#122931: debian-policy: Spelling consistency depend(e|a)ncies in policy 2.3.8.1
On Sat, Dec 08, 2001 at 09:08:16AM -0400, Ben Armstrong wrote: In policy section 2.3.8.1 there are two inconsistent spellings of the word dependencies as dependancies. While correct according to dict [gcide], Then that's a bug in gcide; please file one. -- G. Branden Robinson| Why do we have to hide from the Debian GNU/Linux | police, Daddy? [EMAIL PROTECTED] | Because we use vi, son. They use http://people.debian.org/~branden/ | emacs. pgpYgY41cymzv.pgp Description: PGP signature
Re: Should debian policy require to use debconf for postinst scripts?
On Fri, Dec 07, 2001 at 12:19:51AM +, Julian Gilbey wrote: To pseudo-quote Anthony Towns on this one: policy is not a stick to hit lazy maintainers with. Oh, come now. *Anything* can be a stick to hit lazy maintainers with. Just so long as they get beaten. -- G. Branden Robinson| I came, I saw, she conquered. Debian GNU/Linux | The original Latin seems to have [EMAIL PROTECTED] | been garbled. http://people.debian.org/~branden/ | -- Robert Heinlein pgp4FU85gNpNV.pgp Description: PGP signature
Re: Bug#122817: base-files: Please provide profile.d hook in /etc/profile
On Fri, Dec 07, 2001 at 03:04:39PM +0100, Javier Fernández-Sanguino Peña wrote: You are wrong here. Sample: - I want to provide a package with a lot of useful bash functions/aliases w/o changing any program Write scripts and put them in /usr/local/bin. - I want my users to have a given enviroment for *all* programs. /etc/environment Santiago is right about this. Yes, it frightens me to hear myself saying that. -- G. Branden Robinson| Exercise your freedom of religion. Debian GNU/Linux | Set fire to a church of your [EMAIL PROTECTED] | choice. http://people.debian.org/~branden/ | pgpGurJRmdLIB.pgp Description: PGP signature
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
On Sun, Dec 02, 2001 at 10:46:32PM -0800, Thomas Bushnell, BSG wrote: Branden Robinson [EMAIL PROTECTED] writes: I intend to. I'm sorry to offend you by asking people more familiar with the GNU Emacs Manual to assist. What bugs me is that you've now issued *TWO* proposals without ascertaining their effect first. How many more times are you going to make proposals before getting the facts down?? I hope none, but I fear otherwise. Debian is a collective effort. It is unreasonable to expect a person to vet all 6000 packages in the Distribution before issuing a proposal. One of the strengths of having a large and vital Project is that this kind of work can be parallelized. I did in fact research the impact of my proposals on several GNU manuals -- I don't know of anything else in Debian yet licensed under the GNU FDL -- and discussed the impact in my proposals. Failing to achieve 100% certainty in a proposal's effects is not the same thing as not ascertaining the effect at all. Does your proposal contradict DFSG 3 or not? That is not a determination that you or I am solely empowered to make. If it doesn't conflict: then it either is purely clarificatory, or else it suggests restrictions beyond those required by DFSG. And in practice Debian has applied several restrictions in the past not clearly found in the DFSG. A review of the debian-legal archives will turn up some, but there is no centralized clearinghouse for this sort of information; no effort to collect precedent into a single location. Anthony Towns encouraged doing so. That none yet exists is a poor reason to object to me starting one. If you want it to be purely clarificatory, Not purely, no, and I was rock-solid clear about this in the proposal. If it's a new restriction (and I am not intrinsically opposed to new restrictions), then I ask that it not restrict in such a way as to cause packages currently in main to get thrown out. Asked and answered. Message-ID: [EMAIL PROTECTED] So anything failing DFSG 3 that happens to be in main due to an oversight should be grandfather by my proposal? That's what no problems means, and would be grounds for rejecting my proposal outright as an attempt to repeal DFSG 3. No, the existence of packages with unmodifiable text already in main is something that should inform our process, but cannot be determinative because of the possibility that there is already something in main that should not be. My proposal is a guideline, not a suicide pact. I believe Debian should have a standard a priori the GNU Emacs Manual (for example), and not reason backwards on the assumption that everything that is in main must belong there. People find DFSG violations in main regularly. The intent of my proposal is not to grant categorical immunity to any class of these violations. 1) Do you believe your proposal to contradict the DFSG? No. 2) If the answer to question (1) is no, then do you see your proposal as merely clarifying practice, or do you see it as imposing an additional restriction beyond those currently believed to obtain? Fallacious: false alternative. The proposal clarifies current practice, which is to *RELAX* the restrictions imposed by DFSG 3 and 4. It furthermore attempts to provide rules-of-thumb to help prevent us from relaxing these guidelines too greatly. Message-ID: [EMAIL PROTECTED] As I understand it, a package that makes it into [main] complies to all points of the DFSG. However, your proposal will allow packages that don't fully comply the DFSG to enter [main], if the violation is not too grave. I consider this inconsistent. Well, depends on what you mean by comply. Under what I understand to be your interpretation of comply, everything licensed under the GPL or LGPL would have to be removed from main because the text of these licensed is copyrighted and licensed under terms that forbid modification. I agree that this violates an iron-fisted interpretation of DFSG 3. However, the DFSG and Social Contract were passed when many, many GPL'ed packages were already part of Debian, and as far as I know, few people have ever proposed that GPL'ed software be removed from Debian. This isn't to say that non-modifiable text isn't solely a problem of the FSF's -- the BSD licenses are also affected, and, in a sense, anything with a copyright notice is as well. Interpret DFSG 3 *THAT* strictly and there wouldn't be much left *in* Debian. Just public domain materials. We may as well just fold up shop and quit if that's the case. -- G. Branden Robinson| Human beings rarely imagine a god Debian GNU/Linux | that behaves any better than a [EMAIL PROTECTED] | spoiled child. http://people.debian.org/~branden/ | -- Robert Heinlein pgph8obZmIf32.pgp Description: PGP signature
