Re: gnome, kde, xfce use non-policy main menu
On Wed, Jul 09, 2008 at 09:05:11AM +0200, cobaco (aka Bart Cornelis) wrote: - AFAIK there's no fundamental reason why Debian couldn't switch from menu to .desktop to specify the desktop entries (aside from the necessary coding not having been done to adapt menu to do so) Debian menu files specify things that .desktop files don't and (in their current incarnation) can't. Most notably, the needs field. The .desktop files have a simple boolean flag for runs in terminal. That's inadequate for Debian's needs. For example, Fvwm modules *must* be invoked by Fvwm. It would be pointless and stupid to put them in any menu but Fvwm's. So, the Fvwm modules need fvwmmodule, not text orx11. That's simply not possible with .desktop files. Debian menus are generated. There's no advantage in generating them from .desktop files, because the format of the output of the generator is what matters, not the format of the input. Generating Debian menus from .desktop files would not change a thing, except that we'd have to rewrite the generator. We still need a general purpose menu generating tool for all the systems which don't use .desktop files, and we still couldn't just use the raw input .desktop files as output because we need to filter out things like Fvwm modules. So generating menus from .desktop files has no advantages and lots of disadvantages. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
On Wed, Jul 09, 2008 at 01:11:54PM +0200, cobaco (aka Bart Cornelis) wrote: The OnlyShowIn field of .desktop files, is meant exactly for the above use Ok, that's new. Sounds like a step in the right direction. Anybody know of any other concrete worries? There's also the ?package field (pretty basic, doesn't always match the enclosing package) and the hints. On 2008-07-09, Chris Waters wrote: Debian menus are generated. There's no advantage in generating them from .desktop files, the advantage would be that for the growing amount of programs for which upstream already includes .desktop files (complete with translations), Debian doesn't need to create/maintain one. We'd still have to review them to make sure they meet policy (and that, for example, the ?package field is set correctly), and we still have to generate menus, meaning the input format still doesn't matter. If you want to take advantage of upstream's work in such cases, the simpler thing to do would be to create a tool that converts .desktop files into Debian menu files. That should be _at least_ 100x less work than rewriting the whole menu generator yet again. I could probably write a .desktop-menu converter in a couple of hours. Ask Bill how long it would take to rewrite menu. Then ask yourself how long it would take to replace the existing menu files in all packages in the system. Anyone else got any actual reasons for switching? -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 09:13:11PM +0100, Neil McGovern wrote: On Sun, Oct 15, 2006 at 11:57:47AM -0700, Chris Waters wrote: I don't know if it can always be avoided. [snip lots of good examples where this is unavoidable] I would go for strongly discouraging the practice, but I think that flat-out forbidding it might be excessive at this point. Hence this being should not, rather than must not. We're aware that it's not alwars possible, and you phrased it wonderfully. We want to strongly discourage it, rather than flat-out forbidding it :) Should not says that it's always a bug--just not an RC bug. I'm saying that perhaps sometimes it's not a bug. Although I strongly agree that it should _usually_ be a bug. In fact, as the tcl/tk maintainer, I have a vested interest in making it always be a bug. But I'm trying to bend over backwards to be fair to my dependents...or non-dependents, as the case may be. I would love to see perl-tk built against my packages. But I realize there are valid reasons why it's currently not. Anyway, I'm not going to formally object or anything. I just wanted to toss the notion out and see what happened. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 11:24:22AM +0100, Neil McGovern wrote: We want to avoid packages shipping their own versions of libraries, as then if a security problem or major bug is discovered in that library, we have lots of packages to update, and there's no garuntee we'll even know which packages it affects. I don't know if it can always be avoided. The perl-tk package, for example, embeds its own versions of tcl and tk, but that's an upstream choice. Basically, they maintain their own fork. On the one hand, if a hole is found in tcl or tk, it might go unnoticed in perl-tk BUT on the other hand, there's no guarantee that any other version of tcl or tk will even work with perl-tk! Can we force perl-tk upstream to merge their fork? I doubt it would be easy, but you're welcome to try. Should we re-fork perl-tk on our own? That sounds like madness, but you're welcome to try. In either case, though, I think there's a whole lot of required work before perl-tk could be brought in line with this proposal. Also, some libraries come with compile-time options, and a particular package may need a version built with different options than the main version of the library in Debian. Ideally, we would provide an alternate version of the library package, but it's not always that easy. I would go for strongly discouraging the practice, but I think that flat-out forbidding it might be excessive at this point. At the very least, I think we should get some feedback from the people who are engaging in this practice before passing any absolute bans. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#375502: debian-policy must clarify how sub-policies should be managed
On Mon, Jun 26, 2006 at 06:05:17PM +0300, George Danchev wrote: What you tend to disagree with ? I'm asking for clarification how sub-policies must be handled, and this must be stipulated by the debian-policy. Why must it be stipulated by debian-policy? Official policy is only required when A) there are several options, B) they all work (this is important--if something doesn't work, it's a bug, and doesn't need to be specified by policy), and C) we want to enforce just one option for consistency's sake. In this case, I think the proposal fails test C. I think the advantages of flexibility outweigh the advantages of consistency here. You can have your sub-policy included with d-policy or merely referenced by it, at your choice. If it's included, it will be easier to find, but harder to change. So this choice should be up to the sub-policy maintainers, not a matter for policy. You can even have the sub-policy separate and NOT referenced by d-policy, in which case, it will not have the weight of official policy, but since consistency between packages is a Good Thing, it can still be used as the basis for normal, minor or wishlist bugs. In many cases, this may be sufficient. If you merely want to have ocaml-policy included in or referenced by debian-policy, I will support whichever you choose. But if you're asking for policy to be changed to force your choice, I will oppose the proposal, unless you present better arguments than the mere assertion, it must be stipulated. Which brings us back to my initial question. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Sun, Jun 25, 2006 at 09:07:40PM +0200, Wouter Verhelst wrote: It's not a question of legislating; it's more a question of picking a good option and writing the specification in policy. I fully agree with Wouter on this. Although the specification doesn't necessarily have to be in policy (it could be in dev-ref or the package tools documentation). But I don't think policy is neecssarily a bad place for it either. Beyond telling us what we can and cannot do, policy helps our users understand what they can and cannot expect. I think having a standardized option here to allow -j X to be used if the packaging supports it is an excellent idea. If someone wanted to write up an actual proposal and post it to the policy list, well, we could at least judge the proposal on its merits, and, if it were a good proposal, I would definitely support it. But I don't actually care enough to write a proposal myself. Unless you guys want to wait until I _happen_ to find enough free time :) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Date and Upsteam-URL fields
Date: no. This is pointless. The information is rarely of interest to anyone, and is already available to those who actually want to know, for whatever reason. And in any case, it has nothing to do with policy. Such a field could not be created manually. It would have to be generated by dpkg-buildpackage. Talk to the dpkg maintainers-- they're free to implement this feature if they want. It's not a matter for policy. URL: this has been discussed before many times. No reasonable argument for making it a special field, rather than part of the package description, has ever been put forth. The homepage is a matter of interest to humans, not computers. Therefore, the description is a perfectly lovely place to put it. Not all packages have home pages, and even those that do don't necessarily have anything of interest to Debian users. (Some contain little more than a brief description--already present in the Debian package--and a download link.) It should be up to the maintainer whether including a home page link is worthwhile. I do think that people should be encouraged to include home page links in package descriptions, but this is a matter for the developers reference, not policy. And you can always file wishlist bugs if you see packages that don't have a home page link when you think they should. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Date and Upsteam-URL fields
On Thu, Jun 08, 2006 at 02:48:34PM +0200, Bill Allombert wrote: On Thu, Jun 08, 2006 at 04:28:36AM -0700, Chris Waters wrote: Date: [...] Talk to the dpkg maintainers-- they're free to implement this feature if they want. It's not a matter for policy. I agree it is not a matter for policy. However [...] it is common to do dch -i, do some minor clean up, wait a month, make a change and upload the package without remembering to update the changelog date. Anyone who makes a change and doesn't put it in the changelog should be chastised. But I agree, it does happen, and there may even be cases where it's justified (i.e. do some work, wait a month, update standards-version, then upload). So then, the proper people to talk to are the maintainers of the upload processing software, katie, or whatever. But frankly, I'm still not convinced that the moment of upload is a datum of particular interest to most people. If you just want to know if the package is active, the changelog is the best place to look. Bottom line: the policy list is the wrong place for this discussion. I do think that people should be encouraged to include home page links in package descriptions, but this is a matter for the developers reference, not policy. And you can always file wishlist bugs if you see packages that don't have a home page link when you think they should. I complety agree with that, and I think following the developer reference recommendation (DevRef 6.2.4. Upstream home page) make easy to parse the description for the upstream URL, so computers can find it easily, should they need to: Indeed, I thought it might have been added to Dev-Ref already, but was too lazy to check. :) Bottom line: this _could_ be a matter for policy, but I don't think it should be; I think the entry in Dev-Ref is quite sufficient. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Date and Upsteam-URL fields
On Thu, Jun 08, 2006 at 05:19:00PM -0700, Russ Allbery wrote: Chris Waters [EMAIL PROTECTED] writes: URL: this has been discussed before many times. No reasonable argument for making it a special field, rather than part of the package description, has ever been put forth. The homepage is a matter of interest to humans, not computers. Except that packages.debian.org wants it. As soon as any reasonably common automated process wants that field, having it in the long description is broken. Whatever--packages.d.o already uses it, broken or not. This is an old flame war, and I'm not particularly interested in re-hashing it, especially since I have no personal preference one way or the other. But before it can be added to policy, it needs to be added to dpkg, so this is something that should be taken up with the dpkg maintainers. Until dpkg supports it, there's little point in debating it on -policy. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Date and Upsteam-URL fields
On Fri, Jun 09, 2006 at 10:51:52AM +0900, Kai Hendry wrote: On 2006-06-08T17:49-0700 Chris Waters wrote: Until dpkg supports it, there's little point in debating it on -policy. So that's how it works? First dpkg implements the feature, then we can think about making it policy? Basically, yes. There would be little point in declaring it policy when it is currently impossible for anyone to follow such a policy. :) The devel-reference hack isn't working. Dev-Ref is intended to describe best practices. Which is different from required practices. Since many people (including me) do generally follow the suggestions in Dev-Ref, I would say that it is working fairly well, if not perfectly. Do you really want me to file bugs? Within reason! Mass bug filings, especially for wishlist requests, are generally strongly frowned upon. But if there are particular packages for which you think a Homepage link would be especially useful or desirable, then yes, a wishlist bug report would be perfectly reasonable and appropriate. Also keep in mind that some people may prefer to wait till changes are made to dpkg, rather than modifying their package now, and modifying it again later. Especially for such a low-priority issue. You have to understand, this is a large project with hundreds of people and thousands of packages and lots of other priorities. Not to mention more than a few egos--don't expect to snap your fingers and have everyone kowtow to your whims! :) As I said, this topic has been the basis of flamewars before, so you may want to tread carefully. We owe this to upstream too. I think upstream would love the link backs to their sites. Those that have home pages may--many packages still get by with just mailiing lists and ftp sites, and prefer it that way. And even those that have home pages may not want or need all the extra traffic. Bandwidth can be expensive. That is another reason why this should be left to the discretion of the package maintainer, who presumably knows their upstream's desires in this matter. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
On Wed, Jan 11, 2006 at 11:19:05AM -0500, Kevin B. McCarty wrote: Could Policy be amended slightly to explicitly permit library source packages to create a library-headers package containing include files? I would rather see it modified to not forbid it than add a whole paragraph to explicitly permit it. I think the suggested text is much too long. I'm not objecting to the idea; merely the wording. [proposed paragraph elided] Without this or a similar text, it is not clear to me that source packages creating library-headers binary packages are in compliance with Policy, which currently says The development files associated to a shared library need to be placed in a package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. I would rather see that last sentence modified slightly to allow a little more flexibility. Perhaps changing placed in to placed in or installed by. Or something along those lines. If you can come up with something like that which allows you to do what you want, without going into excessive and unnecessary detail, I can probably be persuaded to second it. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upstream field in package description
On Wed, Jun 01, 2005 at 04:08:54PM +0200, Christian Schoenebeck wrote: Because if it would get part of the policy to be mandatory , then developers would get stressed or at least noticed/pointed to by (hopefully policy-updated) packaging scripts. You misunderstand the purpose of policy. Policy is not a club to beat developers. The purpose of policy is to decide which packages are so buggy that they should be removed from the archive before release! You're putting the cart before the horse. Get the packages to change, and THEN we'll consider changing policy to match. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294351: Please extend 9.4's ellipsis style requirement tocover maintainer scripts and dpkg
On Mon, Feb 14, 2005 at 06:15:34PM +0100, Christian Perrier wrote: Quoting Chris Waters ([EMAIL PROTECTED]): I could say I want guidance from policy on what color of shirt I wear to my next LUG meeting. That doesn't mean it's a matter for policy. Well, I'm not sure that irony is the best way to handle something that could be considered from different points of view...Anyway...:) Hmm, fair criticism. It was mostly just that I found the dpkg maintainer's quote to be very odd, and was trying to show by example just how odd I thought it was. My own opinion about this is that enforcing this in the policy would probably open the door for far too much such changes. Yup, I fully agree. *However*, Thomas is certainly right in trying to get some consistency there. Yes, I very much like Thomas' idea. I just don't think it's a matter for policy, since it's just a suggestion for a single package. Having looked into this a little more, I now think that simple misunderstanding may be why this turned into a major debate. The original wishlist said something like, please have dpkg follow policy. Of course, what Thomas meant was, please copy the style mentioned in policy for something unrelated, not please stop violating policy. And, while hes tried to clarify this distinction later, it's possible that an overworked dpkg maintainer simply didn't take the time to read Thomas' followups with the care that they perhaps deserved. But I'm still not sure. If the dpkg maintainer had answered with a simple yes or no or even I'll think about it, that would have made sense, but the request to make this a policy matter really didn't, and that's why I'd like to get more feedback from the dpkg maintainer (assuming he's not sick of the whole matter already). -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#224509: [PROPOSAL] Correct spurious promise regarding TTY availability
On Fri, Dec 19, 2003 at 04:45:06PM +0100, Tore Anderson wrote: Current policy says a controlling terminal is guaranteed to be available in the maintainer scripts. This is simply not true, for dpkg will happily run without one [...] That's not strictly true. Dpkg calls maintainer scripts, and maintainer scripts may assume that there is a controlling terminal, so technically, dpkg needs a controlling terminal to hand off to these scripts. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#220779: ITP: zope-epoz -- Cross-browser-wysiwyg-editor for Zope
On Thu, Nov 20, 2003 at 05:09:31PM -0500, Joe Drew wrote: On Thu, 2003-11-20 at 14:52, Raphael Goulais wrote: On Thursday 20 November 2003 20:08, Joe Drew wrote: I'm getting a little sick of seeing homepages in long descriptions. Policy clearly says Copyright statements and other administrivia should not be included either (that is what the copyright file is for). (Section 3.4) ... and the Debian Developer's Reference recommends him to do as he has done. There is clearly a disconnect here, then. I believe Policy trumps the developer's reference, but that's not to say that policy can't be changed (and the same for the developer's reference). The only disconnect I see is your a priori assumption that a URL qualifies as administrivia. (I assume you're not claiming that it's a copyright statement.) I think that most of us consider it to be useful and interesting information, neither purely adminstrative, NOR necessarily trivial, and, as such, perfectly reasonable to include in a long description. The whole argument is somewhat fuzzy, of course, since administrivia isn't a real word, therefore, arguing what it really means is rather subjective. But I still think that the vast majority of us would disagree with a claim that a package homepage URL is merely administrivia in any case. Now, I suppose it could be argued that if a home page for a package doesn't contain any useful information about that package (unlikely but possible), then the URL *would* qualify as adminstrivia, but I think you'd have to show that the home page is useless before making such a claim, and such arguments would have to be done on a package-by-package basis. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Original sources, or not
On Fri, Oct 24, 2003 at 01:21:16PM +1000, Glenn McGrath wrote: Perhaps tarballs that arent the original source should remove the .orig and just use .tar.gz, or use some other extension such as debian.tar.gz A simpler approach (and one I've used) is to generate a new upstream version number (e.g. 1.103 - 1.103.0pre104). -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#216492: FTBFS (unstable/all) missing build-dep
On Mon, Oct 20, 2003 at 12:15:17AM -0500, Chris Cheney wrote: What needs to happen to get this into policy? The usual - see /usr/share/doc/debian-policy/policy-process.html (or .txt.gz or .sgml.gz) for details. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#212034: Debian Perl Policy manual uses dependency backwards
On Mon, Sep 22, 2003 at 08:57:16PM -0400, Daniel B. wrote: Since the other package is not dependent on perl, then by your own dictionary's definition, the other package is not a dependency of perl. (Any divergence between us yet?) This is your point of error. The dependency belongs to perl, that's why it's a dependency OF perl's. If the other package had the dependency, then it would be a dependency ON perl, not of. I am dependent on coffee, therefore coffee is a dependency of mine. Strictly speaking, I think there may be a missing 's in perl policy there, i.e. it should say, a dependency of perl's, not a dependency of perl, but the meaning doesn't actually change. It's just a little more awkward (and somewhat more colloquial) the way it's currently phrased. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: New virtual package: myspell-dictionary?
On Thu, Jul 31, 2003 at 07:44:06PM +0200, Rene Engelhard wrote: Packages MUST NOT use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in this list. Note that the exception (except privately...) is large enough to drive a truck through! :) But yeah, I have no problem with this name. It seems well-formed, consistent with existing practice, and doesn't conflict with anything else I'm aware of, and, AFAIK, those are really the only valid reasons for objecting to a proposed virtual package name. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#201182: Not exactly frivolous
On Fri, Jul 18, 2003 at 11:59:04AM -0500, Manoj Srivastava wrote: You are both missing the point. Init scripts are conffiles (with reason). conffiles are not removed when a package is removed, only upon purge. When I remove a package with an init script, I do not want to be bombarded at boot up with extraneous error messages Moreover, init scripts are designed to be run...by init! It is possible to run some (but not all) of them directly, but that's not really their intended purpose. If you're trying to use them for some other purpose, you are, basically, misusing them, and shouldn't be surprised when they don't cooperate. Should return a meaningful value is a valid argument for anything in $PATH. However, init scripts are not in $PATH. (Perhaps some of you hadn't noticed.:) If someone has a need to monitor a particular process (for whatever reason, I freely admit that this is a perfectly reasonable thing to want in some cases), the appropriate thing to do might be to ask for an interface to monitor that process, rather than trying to warp the init scripts for purposes for which they were never intended. In other words, file a wishlist bug against a specific package, rather than trying to wield the club of policy to browbeat everyone. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#193903: marked as done (s/seciton/section in D.2.14. `Distribution')
Manoj (or somebody) wrote in policy changelog: * Could no longer find the misspelling seciton, thus this must have been fixed in a previous change in the manual.closes: Bug#193903 Tsk, bad Manoj (or whoever). If you didn't make a change, there shouldn't be an entry or closer in the changelog. (Not that I've never done this sort of thing myself, but once the issue was raised, I found myself forced to agree with those who object to the practice.) Obviously it's too late to do anything about it now, but I thought maybe if I brought it up, it might help discourage future occurrences. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#162120: Support #162120
On Tue, Jul 08, 2003 at 09:32:26PM +0200, Thomas Hood wrote: If a configuration file contains a syntax error introduced by the admin, maintainer scripts aren't allowed to fix it. Why should the absence of the configuration file (even if that too is considered an error) be treated any differently? Sorry, I was under the impression that recreating the file was the default behavior. Reading thread more carefully, I see that I had this backwards. Given that and the above, I think I tend to side with Manoj on this. Although I think I'm a little less hard-line than he is, and might be willing to consider allowing exceptions if they're well documented. (And, better yet, conditional, i.e. ask the user before proceeding.) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: aren't software authors misestimated?
On Fri, Jul 04, 2003 at 04:03:36PM +0200, Michele Alessandrini wrote: I appreciate every feedback from every single user, and I think that only that feedback can bring an application to higher levels. It sounds like you have a specific complaint, and you're trying to make a general complaint. I assure you that *most* Debianers are quite diligent about passing along anything of interest to their upstream contacts (complaints *or* praise). If you feel that the person who is maintaining your package is not doing so, then you should first take it up with that person. And if that provides no satisfaction, maybe post your complaints to the debian-devel or debian-project lists. One of the duties of a Debian package maintainer is to try to maintain a good relationship with upstream. But it's not like most of us are deluged with feedback either. If you're not getting anything forwarded from your Debian packager, it may be because there's nothing to forward. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#198120: debian-policy: 10.3 init scripts secret options
On Thu, Jun 19, 2003 at 11:23:36PM +0200, Martin Godisch wrote: On Fri, Jun 20, 2003 at 03:13:37 +0800, Dan Jacobson wrote: Also should accept one argument, saying what to do: should be explicit about if it is at least one, or only one. Sorry, I don't understand. What do you want? Overspecification of irrelevent details, as near as I can make out. Dan, policy's job is not to tell you what's allowed. Policy's job is to tell you what's required, and what's forbidden, and that's pretty much it. If you want to add 700 optional arguments to your init scripts, go for it. As long as it does the proper thing when fed the standard required arguments, nobody will care. And because nobody cares...it's not a policy issue. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#197835: [PROPOSAL]: integrated environments are allowed
On Wed, Jun 18, 2003 at 01:32:02PM -0400, Colin Walters wrote: Yes, what we are discussing will not affect newbies. But I imagine a lot of experienced users have EDITOR and especially PAGER set consistently, and this will affect them. If the history of the vi vs. emacs flamewars teach us anything, it's that most experienced users would rather fight than switch when it comes to editors. Frankly, if some stupid app insists on ignoring what I've defined as the One True $EDITOR(tm), I would take it out back, shoot it, drive a stake through its heart, chop off its head, fill its mouth with garlic, and bury it under the crossroads at midnight. That's how evil I think this proposal is. Are you seriously suggesting that if I browse to a text file inside Nautilus, because I have PAGER=less set, it should fire up an xterm or something with less? $PAGER is a different case. I might consider a proposal that $PAGER should only be used for terminal apps. That's historically how it's used for the most part, anyway. In fact, if we look around, I bet we'll find that most X apps ignore $PAGER, whether they're part of an integrated environment or not, and we should probably consider modifying policy to reflect reality here. But touch my $EDITOR at your peril! -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: the 'build' debian/rules target
On Sat, Jun 14, 2003 at 12:48:34AM +0100, Colin Watson wrote: I'm not talking about debian/tmp-a-likes, I'm talking about trees in which you run make. Plenty of packages support that or can easily be made to do so (if nothing else, they can always 'cp -a' the build tree, although that's not optimal). Hmm, yeah, I could do that. It would be a bit ugly and awkward, and I'd rather not. But you're right, it would work. On Fri, Jun 13, 2003 at 12:55:09PM -0700, Chris Waters wrote: I object to a proposal that will make my package buggy just to gain benefits that still won't exist for my package even if I *do* fix it. What proposal? I'm objecting to a proposal that deletes the requirement for the build target to exist. Oh, ok, I thought you were making a counter-proposal. Guess I was just being paranoid, sorry about that. I'll stay neutral on the original proposal. I don't see the benefit of an empty build target in ted's rules, but I don't see any harm either. I suggest that it should do something, and I'm fairly sure that if I could be bothered I could make it do something useful for your packages, but I don't think the onus is on me here. With your suggestion above, I'm sure I could make it do something too. However, * it would require a measurable amount of work, * the cp -a would noticably slow down the build, and * your finger macro *still* wouldn't work - you'd have to edit the rules file or set some variables or something to tell ted where to find its support files. At which point, it's probably easier to type in the _one_ command needed to build a debuggable version of ted.[1] _Especially_ since you probably don't need or want to build both flavors of ted just to debug! [1] it's a long command, but you can cut-and-paste from the rules file, substituting local directories as needed. So, my cost-benefit analysis says that making ted's build target do something is probably not worth it. So even if you did bother to do the work for me, I would probably reject the change, unless you were *really* persuasive. So it's probably a good thing that you can't be bothered. :) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: the 'build' debian/rules target
On Fri, Jun 13, 2003 at 08:57:21AM +0100, Colin Watson wrote: Also, I find 'debian/rules build' a useful finger macro for when I just want to debug something small in a package and don't want to build the actual binary package That's great for a small package which can actually run in place, but many packages need, e.g., to find support files at their proper hard-coded locations or they won't work. I would be very disappointed if this no longer worked consistently. I hate to break it to you, but this already doesn't work consistently. :) My problem with it is precisely what policy says: For some packages, notably ones where the same source tree is compiled in different ways to produce two binary packages, the `build' target does not make much sense. This confuses me. The build target makes perfect sense here; it just builds two temporary trees. But build is generally used as the equivalent of make, not make install. But to create two trees, you need to do a make install (twice). And make install may require root/fakeroot, while the build target is not supposed to need root. So this really doesn't work. My package (ted, in case you're curious) needs to build twice to produce two different binaries, *and* has binaries that won't run unless they find their support files in the proper hard-coded locations. And no, VPATH won't help in this case. VPATH doesn't affect (among other things) cd statements in the Makefile(s). I object to a proposal that will make my package buggy just to gain benefits that still won't exist for my package even if I *do* fix it. I even more strongly object to a proposal that will force me to break another, pre-existing rule (build must not require root) in order to comply. That will leave me in a damned-if-I-do, damned-if-I-don't situation. Never a comfortable place to be. :) I'm willing to listen to counter-proposals that address my issues, but otherwise, this is a firm promise to formally object to any proposal to make the build target actually do something. Now I am sympathetic to the goals that people have stated here (and I too have found debian/rules build handy for debugging). So I think it would be good to have something in our best practices document like: If at all possible, the build target should create something that can easily be debugged. But I think trying to make it a *requirement* for all packages is both pointless and counterproductive. (And will make my head explode.) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: CVS srivasta: Added Apps/Educational to menu subpolicy
On Thu, Jun 12, 2003 at 01:20:23PM +0200, Bill Allombert wrote: It seems no one has anwsered my mail about naming this Apps/Education instead. All other entries are names and not adjectives. Seems like a reasonable argument to me. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#196367: debian-policy: clarify what to do about priority mismatches
On Fri, Jun 06, 2003 at 01:52:58PM +0100, Colin Watson wrote: Every so often, somebody encounters the bit of the policy manual that says: Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. Seeing the must, they then go and file a bunch of serious bugs. And since we do make mistakes here, and since any change can cause a ripple-effect, making other packages suddenly violate this clause, and since violations of this are both quite harmless and hard-to-spot, how about we change it to not be a must? Then the ftp-masters can still try to ensure that it holds true, but people won't freak out about it. Maybe something like: Packages are not supposed to depend on And ...packages may need to be adjusted or overridden by the ftp-masters. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: menu-policy update process
On Wed, Jun 04, 2003 at 06:34:36PM +0200, Bill Allombert wrote: On Thu, May 29, 2003 at 12:49:32PM -0700, Chris Waters wrote: For that matter, what about menu hints? Do we have translations for all of the various hints that different packages use? I retract my claim that translation of hints is not needed. It is needed if you use them obviously. Yes, I was going to respond and point that out, but I got distracted. I'm glad you came to the realization. There are two issue with hints: 1) Nobody understand the hints code, so it is difficult to maintain. Yes, and furthermore, it's been somewhat broken the last few times I've tried it. I really liked it back when it worked, but I've pretty much given up on it. I've dug through the code a few times, and been properly terrified. The sad part is that tree optimization is a pretty standard part of CS -- it shouldn't be this difficult. If it were possible to make it work right, I'd be using it again in a flash. 2) There is no list of hints currently, so this is a problem. I don't know how to fix 1). Point 2) can be used by using debtags[1]. This will probably solve the translation problem. Opinions ? Originally we were going to hold off on forming any sort of policy about menu hints until we had the system in use for a while, so we could see what sort of hints people were going to provide. Well, it's been a while, so maybe we should review the hints we have as a first step, and go on from there. No point in translating hints that we're just going to turn around and remove. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#194974: [PROPOSAL] add Games/Simulation to menu subpolicy
On Tue, Jun 03, 2003 at 10:40:52AM +0200, Josip Rodin wrote: I've also got Air Traffic Controller (atc) and Sail under Games/Simulation (plus Railroad Tycoon 2 and Simcity 3k). These aren't in Debian, at least not that I can see... The former two are part of the bsdgames package. (The latter two are not in Debian, which is why I had them in parentheses.) I think csmash and gtkpool should move to Sports, as should gav, race, trophy, tuxkart and tuxracer. I think lincity, acm/acm4, gl-117, and sabre/xsabre should move to Simulation, as, possibly, should freeciv. This would limit Games/Simulation to simulations of airplanes and life (or whatever that's called). Lincity and freeciv? And, so? Most of the simulators we have right now *are* flight simulators. That's what people have written. But with the popularity of The Sims, I expect to see more and different free simulation games in the not-to-distant future. OTOH, I share the doubt that Conway's Life belongs in Simulations -- I think Toys might be more appropriate. I don't see the reason why billards/pool games fit in sports and airplane simulations do. (I assume you meant airplane simulations don't.) Sports usually involve competition. An airplane racing game (as opposed to a more typical flight simulator) might well fit in Sports. I think a good rule of thumb would be, if you can imagine Television Sports News Reporters covering a real-life game of this sort, then perhaps it could/should go in Games/Sports. (Obviously my own battleball package is pushing the line here, but I think it fits.) Neither of them are Olympic, for example[1]. Motocross games could fit in Games/Simulation as well. There are lots of potential cases for overlap already; most of these games *could* go in Arcade or Strategy too, but Arcade and Strategy are overcrowded as it is. I don't think a little a little ambiguity (and flexibility) will kill us. Chess could go in Strategy, but we put our chess games in Games/Board. I said I think the notion of games-slash-sports is kinda silly. and that's that. In the world of video games, sports-games is a huge and very popular category. We don't have very many yet in Debian, but again, I think it may grow. In fact, I have a couple of projects along this line in the planning stage myself. Just a vague feeling. Well, I'm not firmly tied to any of this either, really. Just tossing out ideas for debate. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#194974: [PROPOSAL] add Games/Simulation to menu subpolicy
On Mon, Jun 02, 2003 at 10:47:30PM +0200, Bill Allombert wrote: On Sun, Jun 01, 2003 at 01:44:48PM +0200, Josip Rodin wrote: On Sun, Jun 01, 2003 at 11:39:32AM +0200, Bill Allombert wrote: So do you motion to remove Games/Sports ? Else if we are to keep it, what should fit in ? I'd first want to see the list of packages already in it... Here the odds: Sports: asciijump battleball billard-gl flyingfoobillard (ski) (ball) (billard) (billard) (billard) Simulation: achilles csmash flightgear gtkpool matrem xlife (lifesim) (tennistable) (flightsim) (billard) (lifesim) (life game) First of all, I want to say that I oppose removing Games/Sports. The Games/Arcade and Games/Strategy categories are already too full; anything that helps reduce the overcrowding there is a Good Thing IMO. I've also got Air Traffic Controller (atc) and Sail under Games/Simulation (plus Railroad Tycoon 2 and Simcity 3k). I think csmash and gtkpool should move to Sports, as should gav, race, trophy, tuxkart and tuxracer. I think lincity, acm/acm4, gl-117, and sabre/xsabre should move to Simulation, as, possibly, should freeciv. As for the argument that sport and game are synonyms, that's silly. Yes, one definition of sport is the same as one definition of game, but that's just one definition, and not even the most popular. This is based on http://people.debian.org/~ballombe/menu/menufiles.tgz Apparently (since you didn't have atc or sail), this is not picking up the entries from the bsdgames package. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: menu-policy update process
On Thu, May 29, 2003 at 02:48:15PM +0200, Bill Allombert wrote: On Wed, May 28, 2003 at 11:37:40AM -0700, Chris Waters wrote: I do note that following menu policy seems to be a request -- it says please, rather than should or must. That pleases me. Unregistered menu section will not be translated The translations should be based on what we actually have, not on what we once thought we might have. Yeah, ok, this is an issue, but I think it's one we should try to solve, rather than using it as an excuse for overly rigid policies. For that matter, what about menu hints? Do we have translations for all of the various hints that different packages use? and may even break KDE(?). If unexpected menu sections break KDE, then KDE has a nasty bug! Remember, users can define their own menu entries for locally installed software, and can create their own sections. I, for example, have /Hosts for machines I log into on a regular basis. (Of course, I've long thought that KDE's method of handling Debian's menu system was badly broken. I complained once, but since I don't use KDE, I never made a big deal about it. I don't even know if my complaint is still valid.) Anyway, that's enough for one post. I'll discuss the Benevolent Dictator idea later, once I've had more coffee and time to think. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#194972: [PROPOSAL] add Apps/Educational to menu subpolicy
Joey Hess (2003-05-27 20:43:08 -0400) : --- menu-policy.sgml.old 2003-05-27 20:40:31.0 -0400 +++ menu-policy.sgml 2003-05-27 20:41:17.0 -0400 @@ -125,6 +125,10 @@ item ptext editors, word processors/p /item + tagEducational/tag + item + peducational and training programs/p + /item tagEmulators/tag item pwine, dosemu, etc./p I'm looking for seconds for this proposal. I second this on the general principal that menu hierarchy change proposals shouldn't need seconds. I also don't object to it, but would have seconded it even if I did object. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku pgpSKsQMgcIw4.pgp Description: PGP signature
Bug#194974: [PROPOSAL] add Games/Simulation to menu subpolicy
On Tue, May 27, 2003 at 08:55:58PM -0400, Joey Hess wrote: I noticed that the majority of packages that create a new second-level menu (in violation of policy) are in Games/Simulation. The whole point of keeping menu policy separate was so that it would be easy to modify without all the overhead of making formal policy changes. I'm a little perturbed that we seem to have lost that. --- menu-policy.sgml.old 2003-05-27 20:40:31.0 -0400 +++ menu-policy.sgml 2003-05-27 20:54:41.0 -0400 @@ -208,6 +208,10 @@ item ptests of ingenuity and logic/p /item + tagSimulation/tag + item + preal world simulations, like flight simulators + /item tagSports/tag item pgames derived from real world sports/p I second this proposal. In fact, I will second ANY proposal to add ANYTHING to the menu heirarchy, no matter how stupid, just to help get it beyond the needs-seconds stage and into the discussion stage, which is where I think these proposals should start! (Much like virtual package names, which is what the menu policy was supposed to be modelled on.) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku pgpndJmgmB5CA.pgp Description: PGP signature
Re: menu-policy update process
On Wed, May 28, 2003 at 12:17:22PM -0400, Joey Hess wrote: Chris Waters wrote: The whole point of keeping menu policy separate was so that it would be easy to modify without all the overhead of making formal policy changes. I'm a little perturbed that we seem to have lost that. Well, it's not clear from reading the various files in /usr/share/doc/debian-policy what the process for updating the menu-policy is supposed to be. Yes, that's what perturbs me. I do note that following menu policy seems to be a request -- it says please, rather than should or must. That pleases me. I personally think that these types of things are better handled by having one person who just comes up with something logical and consistant. I agree if and only if you can find the right person. Any volunteers?... Actually, what the heck, my name is at the top of the authors list. And even though I think it's alphabetical by first name, I'm willing to use that as an excuse to volunteer as menu-policy dictator. (Mwuah-ha-ha-ha-ha-ha-ha-ha!!) AFAIK it was split out of menu in the first place just so we didn't have to rev menu to change it. Speaking fairly authoritatively here (i.e. as the person who authored the split), that was only part of the reason. The reason it was kept separate from policy (rather than just being added as another chapter of policy) was so that it would be easy to change if anyone had any decent suggestions. That information seems to have gotten lost in the mists of time though. (Or in the mists of the -policy archives that I'm too lazy to search...) *shrug* -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Modernising menu manual icons requirement
On Tue, May 13, 2003 at 05:47:15PM -0400, David B Harris wrote: 32x32 is *huge* in a menu, and 48x48 is insane. At least for common use today :) I agree -- icons in the menu should be about the same size as the text, or maybe a little larger. It's a menu, not an image-viewing tool. :) If it's going to be changed, there has to be the basic assumption that the Right Thing(tm) will be done, either via dynamic resizing on the part of the menu app, or conversion in the menu method (the latter will always work). Otherwise, it needs to be left as-is. Actually, there's another option: just add some new variables, and, as with title/longtitle, put a function in /etc/menu-methods/menu.h to choose the best one, which the user can comment out or edit. That should satisfy everyone, and the only tricky part is coming up with the new variable names and documenting them. As an extra bonus feature, one or more of the new variables (say, largeicon) could be used for panels and buttonbars and the like. Of course, if we take this approach, then I'd like to file a wishlist against update-menus to support a new built-in function: firstof($arg1, $arg2...), which would return the first non-empty argument found. Then, instead of: ifelse($var1, $var1, ifelse($var2, $var2, ifelse($var3, $var3, ...))) We could just have: firstof($var1, $var2, $var3, ...) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Modernising menu manual icons requirement
On Wed, May 14, 2003 at 08:21:20AM -0400, David B Harris wrote: On Wed, 14 May 2003 00:30:29 -0700 Chris Waters [EMAIL PROTECTED] wrote: I agree -- icons in the menu should be about the same size as the text, or maybe a little larger. It's a menu, not an image-viewing tool. :) Right :) On the other hand, we would probably have more icons listed in /usr/lib/menu/* if we could just use upstream's. Well, relaxing the 8bpp limit would probably go a long way towards helping there. Scaling an image down a little usually doesn't do anywhere near as much damage as remapping the colors to our very limited set. I know several people who would be providing icons if it weren't for the color limits. Choose the best one implies having multiple icons of different sizes, right? Um, no, if there's only one, then that's obviously the best one. :) Given how trivial it would be to add a scaled pixmap cache for a given menu method and have said method point the generated menu entry to the scaled and cached pixmap, I still think that would be a better solution. It requires new code, which my approach doesn't, it adds more complexity to the system, and is one more thing to go wrong, it will slow update-menus even more (which can already be extremely slow if you have many packages and many window managers installed), and, having looked at the menu code, I'm not sure any modifications there can truly be described as trivial. Aside from that, I suppose you could call it better :) Tell you what - if you promise to have your approach implemented and ready to test by next week, then I'll throw my support behind you. But otherwise, I think we should at least discuss the idea of adding a few new standardized variable names. It's a dead-simple solution, and it's a very flexible solution. And, as Bill points out, we already have a couple (that admittedly aren't used much, but that's mostly because the existing ones aren't very useful, IMO). -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: creating users
On Wed, May 07, 2003 at 01:43:56AM -0700, Pedro Salgueiro wrote: Can a deb package create a user? Yes, with some restrictions, see policy section 10.2.2 (UID and GID classes). Basically, there's a section of UID/GIDs reserved for dynamic allocation by packages. This is 100-999 by default, but the user can change that by editing adduser.conf, so you should use adduser --system to create the user. If you need a specific UID (can't use dynamic allocation for some reason), then things get trickier; I'll assume that's not the case and ignore the issue for now. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#178251: slang: don't do a dh_testroot in clean
On Sun, Mar 23, 2003 at 03:17:54PM +0100, Robert Bihlmeyer wrote: Richard Braakman [EMAIL PROTECTED] writes: What does dh_testroot solve in the clean target? Seriously. I've never understood why people put it in. It gives a slightly more understandable error message, that's all. Which seems like a good enough reason not to forbid it. Personally, I think someone who is entitled to become root should be able to figure out what he has to do on Permission denied errors. True, which seems like a good enough reason not to require it. So, at the moment, dh_testroot in the clean target is not required, but not forbidden. We can see that there are good reasons not to require it and not to forbid it. So we're doing the right thing already, and I see no reason to discuss it further. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#184507: 2.3.9.1 grammar
On Fri, Mar 21, 2003 at 11:55:52AM -0600, Manoj Srivastava wrote: Firstly, this is not broad enough, saying that communicating to the user by hand encompoassed all possible means of communicating, No, it's simply technically meaningless. To me, by hand implies, without the use of a computer (as in, I balance my checkbook by hand). not just stdio. Well, I'm sorry - obviously I don't know what by hand is supposed to mean. I tried to work it out by inference - all the packages I know of that don't use debconf use stdio - but apparently I was wrong. And I'm a native English speaker and familiar with the idiom. Imagine how non-native English speakers must feel! (Not to mention the poor translators.) Why don't you tell me what it *does* mean (or what you think it's supposed to mean), and I'll see if I can come up with some decent wording for that. Or, since it *is* deprecated, and since all *existing* packages use stdio, we could just say stdio like I did. Surely the utter flexibility of an option we're trying to remove isn't crucial? Secondly, the debconf language has become turgid, and in an effort to be absolutely and incontrovertibly unambiguous is beginning to verge on being incomprehensible. Yes, I agree completely. I was more focused on the by hand part, which has been bugging me for ages (thanks to the original reporter for finally bringing it up on the list), but the rest of that section is long overdue for some cleanup too. Package maintainer scripts may prompt the user if necessary. Prompting may be accomplished by hand (deprecated), or by communicating through a program which conforms to the Debian Configuration management specification, version 2 or higher (debconf, for example). Except for the continued presence of the semantically null by hand, I like it. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#184507: 2.3.9.1 grammar
(Wish I'd seen this before I replied to the last message; I could have written a more succinct, all-in-one response. Oh well.) On Fri, Mar 21, 2003 at 11:47:54AM -0600, Manoj Srivastava wrote: This is not an adequate replacement for by hand. What if I pop up an dialog box on detection of X? What if? I would have filed a serious bug if you did that. But then apparently, 40+ years of speaking English as my native language isn't enough to disambiguate what by hand is supposed to mean there. So, what does it mean? Anything at all? Why not just say, you can prompt the user any bloody way you want as long as it works, or use debconf? :) By hand is sufficiently vague to be all inclusive. If we want it to be all inclusive, why not say any way you want? That's pretty all inclusive. And it's clear (unlike by hand). I assumed that by hand was supposed to be excluding *something*. It certainly implies that there are ways of communicating that aren't by hand. So enlighten me (and us). Just what does it all mean, Mr. Natural? If by hand means something (as distinct from not by hand), then we should say what it means. And if it doesn't mean anything, why say it? -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#184507: 2.3.9.1 grammar
On Fri, Mar 21, 2003 at 01:14:55PM -0600, Manoj Srivastava wrote: On Fri, 21 Mar 2003 11:02:20 -0800, Chris Waters [EMAIL PROTECTED] said: Why don't you tell me what it *does* mean (or what you think it's supposed to mean), and I'll see if I can come up with some decent wording for that. From The Free On-line Dictionary of Computing (12 Sep 2002) [foldoc]: by hand 1. Said of an operation (especially a repetitive, trivial, and/or tedious one) that ought to be performed automatically by the computer, but which a hacker instead has to step tediously through. [...] And that's what you think we ought to have in policy? :) I mean, what I got out of that definition is that policy should say, you can prompt the user, as long as the prompts are either far more stupid and tedious than they need to be, or you use debconf. Surely that's not what we want? :) I'm sorry, I was trying an old trick my mom used to use when she'd help me write papers (she was a professional writer and editor). She'd point to some section that was unclear and say, what are you trying to say there? And I'd tell her what I was trying to say, and she'd respond, we'll why don't you just say that, then? :) So, let me try one more time. When policy says, you can prompt by hand or with debconf, what do you think it's trying to say?... -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#184507: 2.3.9.1 grammar
I'd also like to apologize for making a mountain out of a molehill, and worst of all, exaggerating-for-effect, which I *know* is always easy to misinterpret. I would like to assure *anyone* who thought I was taking pot-shots at Manoj that nothing was further from my mind. As for the underlying issue: I still don't like by hand, but I still don't have anything better to offer either, so I'll shut up now. Sooner or later (sooner, I hope), the option will go away; I can live with some ambiguity till then. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#184507: 2.3.9.1 grammar
On Fri, Mar 21, 2003 at 09:27:04PM +, Colin Watson wrote: So, let me try one more time. When you say what do you think it's trying to say, what do you think you're trying to say? I'm trying to say that I think it's *too* ambiguous. Where do you draw the line between what is by hand and what isn't? Can you give me an example of not by hand? (Especially if running X apps counts as by hand, which I would have definitely classified as not-by-hand.) (See how annoying it is to apply that approach to everything? No, actually, I think that was an excellent question; the problem is obviously not that I don't understand, it's that the extreme ambiguity makes me uncomfortable. Thanks for helping to clarify that. I'm kinda getting fed up of policy not being plain English any more because everyone nitpicks at the tiniest little piece of ordinary English idiom.) Now there I agree completely. I'd rather have ambiguity that obscure, unreadable legalese anyday. I was hoping that it was possible to find a *compromise* between *pure* ambiguity and insane precision, though. But maybe not. *shrug* -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#184507: 2.3.9.1 grammar
On Fri, Mar 21, 2003 at 11:05:36PM +, Colin Watson wrote: On Fri, Mar 21, 2003 at 02:43:45PM -0800, Chris Waters wrote: Can you give me an example of not by hand? Not using debconf. That's all that sentence means as I read it: the phrase is just there for emphasis. Oh, I get it. The sentence is trying to say, you can prompt the user directly or through debconf. I wonder why it doesn't just say that then. :) Ok, ok, I'll shut up now, but seriously, thanks. I hadn't thought of that interpretation, and it does, indeed, make a lot of sense. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#178251: slang: don't do a dh_testroot in clean
On Sun, Mar 16, 2003 at 10:53:00PM -0500, Anthony DeRobertis wrote: My personal opinion (subject to change with good arguments against it, of course) is that clean must not require root unless another target has been invoked as root. The argument against this is that the majority of package currently DO require root (or fakeroot, dh_testroot can't tell the difference). Nor does policy *FORBID* this -- it may not MANDATE it, but it doesn't forbid it, and we don't change policy to make a majority (or even a large number) of packages magically become buggy. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#178251: slang: don't do a dh_testroot in clean
On Sun, Mar 16, 2003 at 10:58:18AM -0500, Anthony DeRobertis wrote: I did leave the bug at severity 'minor'. The reason I ever filed it was because it broke some auto-building stuff I was doing. So it did matter at the time. But dh_testroot is part of the clean target in the examples that come with debhelper, and therefore probably in *every* debhelper-based package in Debian (which is the vast majority of packages). Why single out the poor slang developer to pick on? Now don't get me wrong, I don't want to discourage people from filing bug reports. Filing bug reports is generally a Good Thing, and I wish more people did it. But if there's some ambiguity involved, it can't hurt to post to d-devel first (or in the case of policy-related issues like this one, to d-policy), and say, hey, this looks like a bug to me, can anyone comment? -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#178251: slang: don't do a dh_testroot in clean
On Sat, Mar 15, 2003 at 07:21:55PM -0500, Anthony DeRobertis wrote: I parse The clean target may need to be invoked as root if binary has been invoked... as: You're trying too hard to parse it. This is not some silly game to see what sort of frivolous bug reports we can file today. The purpose of policy is to help us make a better system. Try worrying about things that matter. The only other way that I see to read that section of policy is to read it as a simple reminder to people building packages, in which case it should be either removed or changed to a footnote. You're probably right here; at the least, it should be edited to be more clear. Perhaps: the clean target may need to be invoked as root (in case binary has been invoked). But policy is not perfect, nor do we claim it is; there's a lot of sections (especially stuff that got imported from the old developers-reference) that needs to be cleaned up or dropped. It's not our top priority to do this because we have other priorities, and, for the most part, people have common sense. So, the next time you see something that is working fine, and nobody else is complaining about it, and you think it *might* be a violation of the precise letter of policy, please ASK FIRST before filing a possibly-frivolous bug report. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#184507: 2.3.9.1 grammar
On Wed, Mar 12, 2003 at 05:12:12PM -0600, Drew Scott Daniels wrote: On Wed, 12 Mar 2003, Chris Waters wrote: On Wed, Mar 12, 2003 at 02:06:05PM -0600, Drew Scott Daniels wrote: The grammar is ambiguous Common sense makes the resolution of this purported ambiguity pretty clear. [...] Oops, I guess I looked too hard. Well, I think you're over-analyzing what the words *could* mean. You went into such detail, I thought you were trying to be sarcastic. I agree that this does seem like nitpicking, but they are valid points. More or less, yes. That by hand bit always bugged me, too. But you spend too much time trying to prove that a silly person could draw bizzare conclusions from things in policy. I don't really care about that as long as I feel that a sensible person will draw the right conclusions. On the other hand, I do care if there are parts of policy that are unclear or awkwardly phrased, and always welcome suggestions to improve its clarity or readability. My intelligence tells me that if by hand is not replaced then technically I can file serious bugs against packages that do not use hand or debconf. Oh, please. You're saying that the only *possible* interpretation of by hand is by running a program named hand? That's silly. (Especially since there is no such program.) By hand is somewhat unclear, even if you're familiar with the idiom, and downright confusing if you're not. And the rest of the sentence is a little awkward, and not easy to parse. That's all you had to say, and I would have agreed with you right off. Anyway, how about this as a replacement: --- policy.sgml~2003-03-13 02:02:23.0 -0800 +++ policy.sgml 2003-03-13 02:01:43.0 -0800 @@ -1083,11 +1083,13 @@ headingPrompting in maintainer scripts/heading p Package maintainer scripts may prompt the user if - necessary. Prompting may be accomplished by hand, or by - communicating with a program, such as - prgndebconf/prgn, which conforms to the Debian - Configuration management specification, version 2 or - higher. These are included in the + necessary. Prompting may be accomplished by writing to + standard output and reading from standard input, but + this technique is deprecated. Otherwise, prompting must + be accomplished by using a program - such as + prgndebconf/prgn - which conforms to the Debian + Configuration Management Specification, version 2 or + higher. These are included in the filedebconf_specification/file files in the packagedebian-policy/package package. You may also find this file on the FTP site -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#184507: 2.3.9.1 grammar
On Wed, Mar 12, 2003 at 02:06:05PM -0600, Drew Scott Daniels wrote: Package: debian-policy 2.3.9.1 Prompting in maintainer scripts says: Prompting may be accomplished by hand, or by communicating with a program, such as debconf, which conforms to the Debian Configuration management specification, version 2 or higher. The grammar is ambiguous Common sense makes the resolution of this purported ambiguity pretty clear. If you lack common sense, then working on Debian is probably not for you. If the spec were not part of the requirement, why bother mentioning it? and by hand is vague. Hmm, on the one hand, I want to agree with you, but on the other hand, this excessive nitpicking is starting to drive me up the wall. Consider it an intelligence test. If you can't figure it out, then a) stick with debconf or b) go find something less challenging to do in your spare time. :) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Question regarding policy (11.2)
On Sun, Feb 09, 2003 at 09:34:13PM +0100, Josip Rodin wrote: Section 11.2 says: In general, libraries must have a shared version in the library package and a static version in the development package. Since it says the development package, not a development package, it must mean libfoo-dev, in which case putting it in another package is a violation of a must directive. But it also says, in general, which completely undermines the must, as it implies that specific cases may not fit the general rule. In fact, the phrasing suggests to me that this sentence dates back to the time when policy was a compendium of accumulated wisdom and experience, rather than a legalistic weapon used to browbeat recalcitrant developers. (Ah, those happy, innocent days of yore!:) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: docs, docs, and more docs(names of packages and location of files)
On Wed, Jan 15, 2003 at 10:58:03AM -0500, Bob Hilliard wrote: Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] writes: I think splitting out a -doc is always good if it's more than, say, 10% of the pkgs installed size. I agree with the concept, but I think 20% would be a better limit. Of course, the man pages, copyright and changelogs must stay in the package (absent a major policy change). I'm not sure that specifying a fixed percentage is a good idea. If the package is tiny, then 20% might be insignificant, whereas if the package is huge, then 19% might be pretty huge too. I think this is another case where we should let common sense prevail. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 09:18:05AM +0100, Josip Rodin wrote: The new field should be done properly ASAP; the developers' reference can document the existing practice of putting this stuff in the Description: field, but if we have a consensus to make a new field, then we should do that, not concentrate on workarounds. Now I'm confused -- it sounds like we're in complete agreement. :) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 03:14:15PM +0100, Bill Allombert wrote: Policy already mandate upstream site in copyright, and it work: The location of the source is not necessarily the same as the project home page (assuming there is a project home page). Small projects especially may have a home page hosted on the author's ISP, but may simply throw the source onto one of the large sites like simtel. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 06:29:22PM +0100, Josip Rodin wrote: On Wed, Dec 11, 2002 at 04:50:26PM +, Martin Wheeler wrote: [re: my statement that homepage is not (yet) a word.] Neither is 'Debian'. Yes, but we didn't choose this name. More to the point, names aren't necessarily supposed to be words. So the attempted rebuttal is moot. Now for goodness' sake -- grow up. I object to that proposal: I like xtifr better when he's slightly childish. :) Um, thanks, I think? At my age, it's probably too late to attempt to implement any such plan. Furthermore, once the grey hairs appear (as they're just beginning to in my case), the proposition of growing up starts to seem much less appealing. :) Anyway, to get back on topic for a sec, I'm not a grammar nazi. I didn't object to homepage, I merely expressed reservations. And if I really cared, I would have offered some alternatives. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#172630: debian-policy: Clarification on /etc/init.d/foo restart behaviour.
On Wed, Dec 11, 2002 at 01:56:28PM +0100, Bill Allombert wrote: tagttrestart/tt/tag - itempstop and restart the service,/p/item + itempstop and restart the service if the service is already running, otherwise start the service,/p/item tagttreload/tt/tag Agreed; this is already the way most packages behave, and is surely what a user would expect. I second this. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku pgp314DkWg3Tm.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
On Tue, Dec 10, 2002 at 04:49:38PM +0100, Josip Rodin wrote: On Tue, Dec 10, 2002 at 09:03:54AM -0600, Adam DiCarlo wrote: As for the extra work, it doesn't matter. It's not nice to screw around with other people's time like that. But no one is *required* to do anything. (Yet, if ever.) This is a best-practices suggestion that only applies to packages which *have* a meaningful homepage. So, we have a suggestion for what we should do now and what we should do if/when dpgk changes, and anyone who doesn't want to waste their time can wait until dpkg changes. If this were going in policy (you [should/must] have a homepage link in your control file at point X if a site exists that can reasonably be described as a home page for the package), then I would definitely object. (Would create bugs for existing packages, for one thing.) But this isn't for policy, this is for dev-ref. If I have any remaining reservations about this proposal, it's that homepage is not (yet) an English word, IMO. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [devel-ref, draft 2] homepage in description
On Mon, Dec 09, 2002 at 10:57:51AM +0100, Luca - De Whiskey's - De Vitis wrote: I think we don't really need the Screenshot [...] I agree. It's even *less* useful than Author, which I also don't think we need. Upstream source [...] information [is] already available The Homepage is not necessarily the same as upstream source. I think of a homepage as somewhere I can go to get more information before deciding if I want to install the package. It could be a completely different site. Some small projects can't afford their own ftp space, but do have a small web-page, usually created by the author, and hosted by his ISP. So the source will be on some big system, like Sunsite or similar, completely unrelated to the Homepage site. I have to admit, I do like when a package description lists a homepage. I'm planning to start adding this to my own packages soon. But as for the others, I really don't see the point. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [devel-ref] author/homepage in description
On Mon, Dec 09, 2002 at 12:31:48PM -0900, Britton wrote: I don't like this. The pages listed will end up being wrong half the time I think you exaggerate. Especially since this is optional (it's going in devel-ref as part of best-practices, not in policy as a requirement). So, if the maintainer knows that the home page is subject to change without notice, then he won't put it in the description. But many packages have home pages that haven't changed in decades, and aren't likely to. and google can find homepages very well and everybody knows it, so what is the point in adding this? Convenience. Someone browsing our package pages can just click through instead of jumping to google and manually typing in the package name (and maybe mistyping it). This works right now. And we could add a jump-to-homepage feature to dselect or aptitude in future, for further convenience. (Probably not in dselect, I admit.) Plus, google may not always help. if you search google for, say, rat, you're probably going to find more information about rodents than about the Debian package named rat. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On Thu, Nov 14, 2002 at 11:51:28AM -0900, Britton wrote: I don't agree at all that a half-assed man page is better than undocumented, especially if upstream has taken the trouble to provide better documentation in some other form. Isn't that backwards? The worse the upstream documentation, the greater the need for a GOOD, detailed man page, IMO. Now, if you're talking about a lousy man page that doesn't even tell you where to find the better documentation, then I'd agree. But I wouldn't call that a half-assed man page. I'd call that full-assed. (Or do I mean no-assed?) In fact, I might go so far as to say that unless your man page is *clearly* better than undocumented(7) (at least for your specific program), then it is in no way good enough to be called half-assed. And I ought to know, as I've written several man pages for the project that I think nearly everyone will agree are half-assed. :) A minimal man page, carefully maintained, might be worthwhile. You say po-TAY-to, I say po-TAH-to cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
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. Excuse me? This is an old proposal which has been much debated and much revised. It was also generally well-received, and I'm not quite sure how it slipped between the cracks for so long. Colin's new revision was proposed on Oct 30, and he suggested two weeks debate (which seems more than fair since this was already an old proposal). Some minor changes (i.e. s/must/should/) were proposed by me and Mark Brown, and since the discussion period IS NOW UP, the text posted by Manoj to -devel (which incorporates the minor changes) IS INDEED THE FINAL FORM! The decision to forward this to -devel (and to make misleading claims about its status) seems to have been a unilateral decision on Manoj's part. If he weren't professing his own love for the proposal, I would suspect an underhanded attempt to undermine the proposal for reasons unstated. If I were really paranoid, I'd speculate about why the policy editors ignored the earlier versions of this proposal, which, after much debate, *was accepted*! But I won't go there. But I am perturbed by Manoj's attempt to drag the debate out further when this proposal has been debated to death since June of 1999! And all objections have been answered or addressed. And it has a full complement (more than) of proper seconds already, and no remaining objections. I am also perturbed that Manoj, who WROTE our current policy update policy seems to be completely and deliberately ignoring that policy with his post to -devel. Manoj, what gives? (If you actually object to the proposal, please, object!) Anyway, while I have no objections to input from -devel readers, I have to say that anyone who's concerned about how changes in policy may affect them should already be subscribed to -policy. Now, if this were my proposal, I might allow a further three days discussion, out of respect for Manoj. I think three days is more than adequate for a three-year-old proposal. But at this point, it's Colin's proposal, and unless *he* decides to extend the debate, I think this proposal lives or dies TODAY! (And with many seconds and no objections, that means it lives.) And just to quell any last-minute fears people may have, who missed the earlier, extensive debates: this proposal does NOT forbid the use of undocumented(7). The use of undocumented(7) HAS ALWAYS BEEN A BUG! This is why current policy REQUIRES you to have an open bug report before using undocumented(7). This proposal simply removes the APPARENT blessing of policy from what is, and always has been, a buggy state. Existing packages will be no more buggy than they already have been. At most, this may help to remind people to file some bug reports that should have been on file long ago! -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On Wed, Nov 13, 2002 at 12:22:58PM -0900, Britton wrote: Along with potential false hopes during load time, the undocumented page provides pointers to places where documentation may be found. An actual man page would do a better job of that. The point of this proposal is that people should provide man pages! Lots of people seem to think that as soon as they make a link to undocumented(7), their job is done. Well it's not! If you can create a debian/control file, you can write a simple man page that (at least) explains EXACTLY where the full documentation for this program is to be found -- not just a list of possible places to start hunting. Even a half-assed man page is better than using undocumented(7), and I don't believe there's a person in this project who can't generate a half-assed man page in about 15 minutes, given some example man pages to start with. Does that answer your reservations? -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On Thu, Nov 14, 2002 at 01:13:24AM +, Colin Watson wrote: I've just uploaded man-db 2.4.0-11 with the additional text in the error message on an experimental basis; Cool! Go Colin! Yay! I still think that DDs who can't even be bothered to provide at least a *paragraph* worth of man page (with, presumably, a more useful SEE ALSO section) should be severely beaten, but I suppose that's outside the scope of policy. :) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On Wed, Nov 13, 2002 at 08:00:27PM -0600, Manoj Srivastava wrote: Chris == Chris Waters [EMAIL PROTECTED] writes: Chris since the discussion period IS NOW UP, the text posted by Chris Manoj to -devel (which incorporates the minor changes) IS Chris INDEED THE FINAL FORM! Well, no, since Colin agreed that editorial changes to the SGML were indeed permissible. I'm sorry, but since you made a point of saying this is not the final form, I assumed you meant that *substantive* changes were still needed. Not fine-tuning to the markup. I have always assumed that policy editors are free to fine-tune the markup when necessary. Chris The decision to forward this to -devel (and to make misleading Chris claims about its status) misleading? See above. Perhaps I merely misinterpreted your statement. Chris he weren't professing his own love for the proposal, I would Chris suspect an underhanded attempt to undermine the proposal for Chris reasons unstated. Chris If I were really paranoid, I'd speculate about why the policy Chris editors ignored the earlier versions of this proposal, which, Chris after much debate, *was accepted*! But I won't go there. You already have. No. I won't deny that these thoughts crossed my mind (as that would be an obvious lie), but I didn't believe them for a second. I'm sorry if I seem a little angry, but this has been dragging on for three years, and I'm tired and frustrated with the topic. Chris But I am perturbed by Manoj's attempt to drag the debate out Chris further when this proposal has been debated to death since Chris June of 1999! And all objections have been answered or Chris addressed. And it has a full complement (more than) of proper Chris seconds already, and no remaining objections. Well, I think because getting input from the general developer body is never a bad idea. I think that major changes in packaging ought to receive wider circulation than just the policy list. I have no problem with that. What major change in packaging did you have in mind? This proposal clearly is not any such thing! * Packages without a man page are buggy. They will continue to be buggy. * Use of undocumented(7) is a bug (it requires an open bug report on file). Use of undocumented(7) will continue to be a bug. This will not prevent anyone from using undocumented(7). If they were willing to live with a buggy package before, they will probably be willing to live with a buggy package afterwards. The only real change is that it's going to be harder for people to *pretend* their packages are bug-free when they lack man pages. Also, because I am more interested in doing the right thing, and looking at the spirit of the consensus building process, rather than being a rules lawyer. You do agree that resolving any flaws we may have overlooked is more important than not missing a deadline, don't you? No, fine, wonderful, nobody has found any flaws in this *trivial* proposal in the *three years* since it was originally proposed, but maybe an extra few days in front of a wider audience will reveal the subtle way in which it can destroy the whole project. And stop being paranoid. I'm not paranoid, I'm tired and frustrated. I was involved in the discussions that lead to the original proposal, I answered people's questions about the proposal during the original discussion period, I went off and browbeat the lintian maintainer into adding a warning about the use of undocumented(7) in order to address someone's reservations. The proposal was already accepted once, and then dropped on the floor (presumably accidentally). Colin noticed, revived it, brought it up-to-date. And I just don't see why this already-accepted-once proposal is being such a big deal. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On Tue, Nov 12, 2002 at 12:53:35PM +, Colin Watson wrote: Er, um, oops. :) Thank you for spotting that. --- policy.sgml.orig 2002-11-12 12:50:40.0 + +++ policy.sgml 2002-11-12 12:51:30.0 + @@ -7485,22 +7485,22 @@ page included as well. /p - p - If no manual page is available for a particular program, - utility, function or configuration file and this is reported - as a bug to the Debian Bug Tracking System, a symbolic link - from the requested manual page to the manref - name=undocumented section=7 manual page may be - provided. This symbolic link can be created from - filedebian/rules/file like this: - example compact=compact -ln -s ../man7/undocumented.7.gz \ - debian/tmp/usr/share/man/man[1-9]/varrequested_manpage/var.[1-9].gz - /example - This manpage claims that the lack of a manpage has been - reported as a bug, so you may only do this if it really has - (you can report it yourself, if you like). Do not close the - bug report until a proper manpage is available./p +p + There should be a manual page at least for every program. If + no manual page is available, this is considered as a bug and + should be reported to the Debian Bug Tracking System (the + maintainer of the package is allowed to write this bug report + himself, too). Do not close the bug report until a proper + manpage is available.footnote + p + It is not very hard to write a man page. See the url + id=http://www.schweikhardt.net/man_page_howto.html; + name=Man-Page-HOWTO, ttman(7)/tt, the examples + created by ttdebmake/tt or ttdh_make/tt, or the + directory file/usr/share/doc/man-db/examples/file. + /p + /footnote + /p p You may forward a complaint about a missing manpage to the This version gets my second, as promised. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku pgpF2IO7Dj11W.pgp Description: PGP signature
Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On Wed, Oct 30, 2002 at 11:09:25AM +, Colin Watson wrote: Here's an updated version of Roland Rosenfeld's diff: [...] + There must be a manual page at least for every program. If This would make it an RC bug if no man page exists. I don't think that's what we want. (I know it's not what I want.) Change must to should and I'll renew my second. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku pgpohcBSeQsBd.pgp Description: PGP signature
Bug#167004: gnome-wm
On Wed, Oct 30, 2002 at 03:29:09PM +0100, Christian Marillat wrote: Colin Walters [EMAIL PROTECTED] writes: Christian, could you look over it? The policy maintainers indicated to me on IRC that they would only add it to policy after it had been integrated, so if you are in agreement, I will commit support to our gnome-session CVS for it, and supply patches to the metacity and sawfish packages. I disagree with that. Users already don't know how to setup the default x-window manager, and now you want to introduce an new update-alternative... I think you're missing the point. If eczema-window-manager (or whatever this is called is introduced, and gnome depends on and uses this instead of x-window-manager, then users won't have to know anything! It'll Just Work(tm). Here's the scenario: twm and metacity are both installed. Now, twm wins the race for x-window-manager, because it's a better qualified standalone window manager than metacity. However metacity wins the race for eczema-window-manager, because twm isn't in that race, so when gnome starts, and runs eczema-window-manager, the user gets metacity. No knowledge by the user is required, and everyone's happy. (And BTW, I think desktop-window-manager might be a better name.) 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. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
/bin/sh alternative (was Re: Essentialness of awk)
On Sat, Sep 28, 2002 at 01:18:31PM +0200, Santiago Vila wrote: Well, yes, more or less. In the example about gawk replacing mawk you'll see that at all times there is a working awk. I don't see a fundamental reason why this should not work for dash and bash. It works for mawk/gawk because the alternatives mechanism is already set up. The problem with dash/bash is not that alternatives wouldn't work if it were set up that way. It's getting from where we are now to the desired state. And I doubt it's impossible, but it's a lot of work -- one attempt already failed and hosed a lot of people's systems. And the fact is that the current system, while less than ideal, does work. The number of people who would benefit from an improved system is actually pretty small -- I suspect that 99% of users (including ourselves) are content with bash as /bin/sh. And the rest *can* do what they want, it's just not as easy as it could be. So it's a lot of work for not much gain. OTOH, if you feel so strongly about it, perhaps you'll be motivated to come up with a transition plan that works in all cases, and test it, and present it to the appropriate maintainers. I certainly would not object. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#161455: debian-policy: reference to ash outdated
On Thu, Sep 26, 2002 at 11:34:32PM +1000, Brendan O'Dea wrote: bash is an essential package and therefore must (§2.3.7) supply all core functionality when unconfigured--which precludes the use of update-alternatives (run when configuring the package) if you consider /bin/sh as being part of bash's core functionality. IIRC, there was even an attempt to make bash use update-alternatives, which resulted in much chaos and breakage (probably similar to the more recent perl case). Basically, what it comes down to is: while I think most of us wish /bin/sh were managed by update-alternatives, as the poet says, you can't get there from here. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#60979: What /etc/init.d/xxx restart does?
On Fri, Sep 13, 2002 at 07:22:39AM +0100, Oliver Elphick wrote: On Fri, 2002-09-13 at 02:50, Chris Waters wrote: It tells you by its silence -- if the service actually had started or stopped, then it would have printed a message. But the Unix norm is that silence means success. Failure produces a message. Well, yes, that's the norm for normal commands, but these aren't normal commands. They aren't in anyone's path, and under normal circumstances, they're only called indirectly by init when you change runlevels. And I believe the idea is that when you change runlevels, you want to know which services start or stop, but don't really care about those that continue running (or not running) uninterrupted. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#60979: What /etc/init.d/xxx restart does?
On Thu, Sep 12, 2002 at 10:30:21PM +0100, Oliver Elphick wrote: On Thu, 2002-09-12 at 18:43, Robert Bihlmeyer wrote: Starting and stopping a service should be idempotent, i.e. further attempts should silently succeed. If I start something that is already started, I want it to tell me - It tells you by its silence -- if the service actually had started or stopped, then it would have printed a message. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
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 confess that I like update-init better myself, but I have to ask:
is the transition worth it? I have a fairly modest installation here
(recently rebuilt after a HD crash), and I see this:
~ $ grep update-rc.d /var/lib/dpkg/info/*{pre,post}{inst,rm}|wc -l
88
Which suggests that there's somewhere between 20 and 44 packages using
update-rc.d right now. Enough to justify a transition plan at the
very least. Enough that I'm questioning (though not formally
objecting to) this change.
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [RFC] *-rc.d - rc.d-* transition
First, I'd like to say that I'm fairly neutral in this debate. None
of my packages will be affected either way, and I have no strong
feelings about the namespaces involved. Nevertheless, I think there
is one argument against the proposal which has been completely
overlooked: update-rc.d is consistent with other similar debian
utilities like update-menus and update-alternatives. This is not a
strong argument, but I don't see any strong arguments on either side.
On Sun, Sep 08, 2002 at 01:48:35PM -0300, Henrique de Moraes Holschuh wrote:
The arguments for the transition were, as far as I recall:
1. Since we'll be adding more programs to update-rc.d, we should have fixed
that in the first place (I replied too late to the guy when I heard
this argument :-) )
That's not an an argument, since it's based on the _conclusion_ that
we should change the name. Indeed, IF we decide to change the name,
we should probably try to do it sooner rather than later for this
reason, but that begs the question: should we try to change the name?
2. Far easier stem-searching while working with the stuff (rc.dtab),
makes far more sense, too.
That might make sense if this were something that people used
directly, but, as argued in point 5, people generally don't. In any
case, this argument is more applicable to update-menus or
update-modules or update-inetd. If this is really a valid argument,
then you should be trying to get all of those changed as well.
3. Clean namespace and proper grouping of related utilities. rc.d-{update,
invoke, policy}, especially when the upcoming (when they're ready)
init.d-* scripts (for parallel execution and dependency processing in
init scripts) are taken into account.
I don't understand why rc.d-* is any cleaner of a namespace than
*-rc.d. I think this argument is mere noise.
4. update-rc.d should have been called rc.d-update in the first place
Another example, like point 1, of taking your conclusion and calling
it an argument. -2 points for circular reasoning and begging the question.
5. there is no real reason not to do the change in the first place, users
are NOT supposed to be using rc.d-update directly anyway
The same could be said of update-mime, update-fonts-alias, etc. But
it's not true. There are two reasons. Neither are strong reasons,
but then i haven't seen any strong reasons to make the change.
The first reason for not making the change is that it is currently
consistent with other, similar update-foo utilities. Changing it
may make it harder for DDs to find if they search the update-*
namespace (which is what I usually do in similar cases). The second
reason is also about consistency: during the transition, there will be
some packages using update-rc.d and some using rc.d-update, which may
confuse people studying our packages. Not strong reasons, but reasons
nonetheless.
Against these weak reasons we have, what? The idea that a .d suffix
should indicate a directory? Well, most directories do NOT have a
.d suffix. And it's pretty obvious to anyone who looks that
update-rc.d is not a directory. The fact that it doesn't have the
directory bit set, the fact that you can't cd into it, the fact that
it's located in /usr/sbin, and the fact that file(1) calls it a perl
script: all of these are big clues that you're not dealing with a
directory here.
Without any strong reasons on either side of the debate, I'm inclined
to vote for the status quo.
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#155680: PROPOSAL ] bump priority of window managers which support WMSP
On Tue, Aug 06, 2002 at 02:16:32PM -0400, Colin Walters wrote: + If the window manager complies with the url [the netwm spec] + name=Free Desktop Group, add 30 points. 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. Right now we have 20 points for menu, and 10 points for the ability to restart a different window manager. How about if we go for 30 points for menu, 20 points for netwm, and 10 for switching? Or something like that? 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 still want to hear what Branden has to say about all of this, too.) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#155680: PROPOSAL ] bump priority of window managers which support WMSP
On Tue, Aug 06, 2002 at 02:16:32PM -0400, Colin Walters wrote: The attached patch should speak for itself. This came about because users would often install 'x-window-system' (installs twm) and 'gnome2' (installs metacity) in order to get a GNOME 2 desktop, but twm had a higher alternatives priority than metacity. I'd like to hear some feedback from X experts on this, esp. Branden. I also think it would be good if Gnome had some sort of tropism for metacity/sawfish outside of the x-window-manager alternative, but that's somewhat orthogonal to this proposal. However, I have a gut feeling that window managers which provide more functionality emon their own/em should generally have higher priority than those which don't. Unfortunately, I have the impression that this would doom metacity to a fairly low priority. Which is why I think Gnome should have its own internal tropism for its favored window managers. I'd also like to hear from the KDE, XFCE and GNUstep camps, to see if they really buy into this new standard you refer to. But bottom line, if Branden approves, then I will probably go along. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Tue, Jul 30, 2002 at 04:51:55AM +0300, Richard Braakman wrote: On Mon, Jul 29, 2002 at 05:49:33PM -0700, Chris Waters wrote: After a first skim-through the list, I find myself a little perplexed -- editor is not an official, policy-blessed virtual package name, but lambdamoo-core is. I think it's safe to say that something's wrong with this picture. (And it's just the tip of the iceburg, of course.) That's because editors are special :) From policy 12.4: Ok, fair enough, but then substitute c++-compiler or nfs-client or radius-server for editor. All are actual virtual package names in use in the system, and all are probably useful, but none are officially blessed. Unlike lambdamoo-core. :) Anyone who hasn't looked may find the list of actual virtual packages (which can be seen in aptitude) interesting and informative, and possibly a little frightening. The virtual-packages changelog shows that an editor entry was actually added and then removed in 1996. Then I won't plan to propose that we re-add it. :) But I am starting to think that we should stop and examine our list of officially blessed virtual package names, our list of _actual_ virtual package names, and see if there aren't a few that should be added to or removed from the former. And since I've already opened my big fat mouth and volunteered to document the interfaces for the official virtual packages, I'd rather not get stuck with this job too. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Mon, Jul 29, 2002 at 11:17:57AM +0200, Wichert Akkerman wrote: A virtual package is a means to indicate a package provides a certain interface, not some functionality. Some virtual packages (mail-transport-agent, c-compiler, httpd, most of *-server) clearly do have an associated interface. Some (mail-reader, www-browser, audio-mixer) clearly do not. Functionality is useless if you can't use it in a standard way. If that were true, then nothing would depend on mail-reader or www-browser or audio-mixer. But things do. If policy is currently unclear on this we should improve the policy text. It definitely makes sense for each virtual package to specify the exact interface it represents. For those virtual packages which have an assumed interface (which is probably most of them), I fully agree. Good: Documenting interfaces for virtual packages. Bad: throwing out virtual packages which lack an interface to document. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Mon, Jul 29, 2002 at 10:26:52PM +0200, Wichert Akkerman wrote: Ok. I think we are actually all in agreement now, Can someone please volunteer to go through the list of virtual packages and document them properly? For each virtual package we should document * a description of what it should be used for * a complete description of the interface packages should provide if that is relevant for that virtual package I'll take a stab at it. I made need to consult about some of the entries. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Mon, Jul 29, 2002 at 10:26:52PM +0200, Wichert Akkerman wrote: Ok. I think we are actually all in agreement now, Can someone please volunteer to go through the list of virtual packages and document them properly? For each virtual package we should document After a first skim-through the list, I find myself a little perplexed -- editor is not an official, policy-blessed virtual package name, but lambdamoo-core is. I think it's safe to say that something's wrong with this picture. (And it's just the tip of the iceburg, of course.) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/doc
On Mon, Jul 22, 2002 at 12:02:56PM +0200, Santiago Vila wrote: retitle 69311 [PROPOSAL] Symlinks in /usr/doc not mandatory anymore. thanks [ I naively proposed something like this after the release of potato, but it was not the right time... ]. Proposed patch to current policy: [actual patch elided, the date and BTS should provide sufficient ID] You (barely) beat me to the punch, so I join the chorus of seconds. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku pgpnBEEn01rmJ.pgp Description: PGP signature
Re: /usr/doc
On Sun, Jul 21, 2002 at 03:32:46PM -0500, Adam Heath wrote: So, you'd rather see a half-empty /usr/doc, which is not very useful, then to have a script, that links /usr/doc to share/doc, and would not cause any loss of functionality? Oh, no no no! We're not reopening this can of worms! We had weeks of loud arguments about how to do this, and finally had to resort to the tech ctte to get a ruling. Now we have a plan, and we're sticking with it! Yes, a half-empty /usr/doc is the next stage of the plan, just like a half-empty /usr/share/doc was an earlier stage of the plan. /usr/doc is [...] On its way out. Learn to live with it. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/doc
On Sat, Jul 20, 2002 at 12:56:10PM -0400, Joey Hess wrote: So would anyone murder me if the code in debhelper to make postinst scripts manage /usr/doc links just went missing? We really should make the corresponding change to policy too, but I won't complain if debhelper leads policy here by a little bit. In fact, I promise to reserve my murderous wrath for the policy editors if they neglect to make this planned change before sarge is released. :-) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Mon, Jun 17, 2002 at 10:45:09AM -0500, Steve Greenland wrote: Because it's not reliable. At least some portion of it is subject to the random whims of the package maintainers (or, far more likely, the random whims of bug reporters and a package maintainer who is (understandably) unaware that a few of Debian's umpteen thousand packages rely on that particular binary being in /bin). I'm sorry, but if the maintainers of essential packages are unaware of the fact that those packages are essential, and that major changes in those packages may have an impact on lots of other packages, then we're already in deep trouble. In any case, breakage happens. I think it's extremely unlikely in this case, but it happens, and we deal with it. If such a change were made, there would be an immediate uproar, thousands of bug reports would instantly be filed, and the maintainer would face the wrath of everyone who depends on the old order. If the maintainer were really as much of a blows with the wind person as you suggest, then any such change would be almost instantly reverted. In any case, the number of packages that need to run early in the init process is probably more in the dozens than the thousands. Such extreme hyperbole makes me very suspicious. Is there some sort of subtle power play going on here? If so, I disapprove. If you have a problem with the shellutils (or whatever) maintainer, please just say so, so those of us who are still trying to grasp this issue on technical terms will understand what's really going on. From where I sit, this looks superficially technical, but smells political. Especially since I haven't seen any good technical arguments from the supporters of the proposal. If a change in an essential package were to break dozens (or, hyperbolically, thousands) of packages, that would be a critical bug! Forbidding such a change in policy would add nothing to the bug severity in that case. And, if such a change were really necessary, for some reason, then forbidding it in policy would simply mean one more package that would have to be fixed (i.e. policy itself) to let such a change go through. I see no benefit to adding this to policy, only potential drawbacks. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Sun, Jun 16, 2002 at 02:17:12PM -0500, Steve Greenland wrote: It's not superfluous: if it's up to the developer, then they can move a binary from one to the other with no warning or discussion. Not if that binary has its location specified in the FHS, which most of the ones we're discussing do. The FHS says that sed goes in /bin, so that's not an issue -- Branden can use sed instead of cut. As for command -v, I don't see any advantages it has over type. Both produce output that requires parsing if aliases or shell functions are involved. And type is a POSIX shell feature. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Objection to change made in debian policy
First of all, Wichert, you set Mail-Followup-To to debian-policy@lists.debian.org, [EMAIL PROTECTED]. I don't think that followups to [EMAIL PROTECTED] are appropriate. (I'm not even sure that a CC to the policy list was necessary, since bugs against policy seem to automatically go to the policy list.) On Mon, Jun 03, 2002 at 08:48:41PM +0200, Wichert Akkerman wrote: Personally I increasingly feel that make is not the right format for debian/rules. Without disagreeing with your proposal, I'd like to point out that there seems to be a fairly trivial workaround: #! /usr/bin/make -f build: debian/myrules build binary-arch: debian/myrules binary-arch binary-indep: debian/myrules binary-indep binary: debian/myrules binary clean: debian/myrules clean Then debian/myrules could be any sort of script you want. It could even be a binary, built on the fly, if you really wanted to get tricky. Granted, it's a bit redundant and silly, but it's policy-compliant and should provide the flexibility you need, at least from now till whenever policy becomes unfrozen again. And frankly, if there were some packages using this silly workaround, I'd be that much more likely to support a proposal to modify policy to make it unnecessary. (Not that I oppose the proposal in the slightest.) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#108416: Bug#139957: period at the end of short description?
On Sun, Mar 31, 2002 at 01:39:22AM -0500, Colin Walters wrote: I'm thinking of subtitles for technical works, not works of fiction. I'm not sure programs necessarily fit in the former category. What about games? I've been messing with dosemu lately, trying to get some old games up, so I've got on my desk here: Masters of Orion II: Battle at Antares, and Dune II: The Building of A Dynasty. Taking one example from my bookshelf: I'm not saying that subtitles can't be descriptive, I'm saying that they're not necessarily descriptive. That's not their primary role. Consider: Homicide for Dummies: A Reference for the Rest of Us. Anyway, as the Dune II example shows, even professional commercial publishers don't always follow the rules for capitalization in subtitles. :) Anyway, I have the feeling that this dead horse has learned all he's gonna, so I guess I'll stop flogging him now. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#108416: Bug#139957: period at the end of short description?
Note that whatever we decide on, I'll probably have to change something, as most of my packages are adopted, and have little or no consistency in how their descriptions are written. I think this allows me to be fairly unbiased, as I can't really argue for the way my packages currently are, just in order to avoid the need to change them. On Thu, Mar 28, 2002 at 09:06:04PM -0500, Colin Walters wrote: To make up for this (in addition to the fact that I'm working on #134106 at the moment :) ), I'd like to add something new to the discussion. I assert that the short descriptions are not titles nor sentence fragments per se; rather they are subtitles, like for a book. I am uncomfortable with this view. A title (or subtitle) is capitalized the way it is because it is, more or less, a proper name. A name may be descriptive, or it may be merely evocative or suggestive, or none of the above. We want descriptive, not merely evocative or suggestive, and certainly not none of the above. Doctor Strangelove or: How I Learned to Stop Worrying and Love the Bomb: here the subtitle is definitely evocative, but not very descriptive. A package might have an official upstream subtitle (something like, Pathologically Eclectic Rubbish Lister), and that's probably not what we want. We want a short description. Really we do. So, I think that's what we should ask for. Most short descriptions follow the template: packagename is a(n) short-description That's not the rule subtitles follow, because titles (sub or otherwise) are names, not (necessarily) descriptions. More practically, as Branden points out, it's easier to add capitalization in a display program than it is to take it away. To add capitalization, you merely need to filter a handful of small words that don't get capitalized. To take away capitalization, you need to know every proper name and every acronym that might be used in a description (because these shouldn't get de-capitalized). So, to summarize, treating the short description as a sentence fragment (or, my preference, as a noun clause) is both more correct (IMO), and results in a more flexible system. Thinking about this has inspired me to come up with an official subtitle for WMRack (which I'm currently upstream for): The Wonderful, Magical Rack of Sound Bytes. I think it's a fine subtitle, but I do not think it would be an appropriate short description. I hope you all agree. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
On Tue, Mar 26, 2002 at 01:10:14AM -0500, Colin Walters wrote: + 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 (`.'). I'd rather have this be a guideline than a rule. So, I'm not sure policy is the right place. (Sure wish we had someplace else where guidelines could go.) But if it does go in policy, I think should might be too strong. I'd rather have it specify a noun clause instead of a sentence fragment (if we're going to specify anything). I agree about the full stop. (Although I still think should might be too strong.) If we're going to discuss leading caps or not, I agree with Branden: not unless it would be capitalized for other reasons (i.e. GNOME). Maybe we can make it a footnote. (Footnotes aren't normative, are they?) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#137172: removing Dan Quinlan's addr from policy
On Thu, Mar 07, 2002 at 12:51:04AM -0800, Chris Waters wrote: But if [Dan Quinlan] is no longer the contact, then I think that we do need to remove [his] name/email. Hi, this doesn't seem to be moving forward. There's only one second. We either need a second second (as it were), or we need some policy editor to decide that a change of this nature doesn't require seconds (a more reasonable approach IMO), and just to fix it. To recap: Dan Quinlan is no longer the FHS contact, and would like us to remove his email from policy. This is a simple administrative change, with no functional effect on Debian whatsoever, but it needs to be done. Freeze or no freeze. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#137172: debian-policy: FHS section requires updates
On Wed, Mar 06, 2002 at 09:58:29PM -0800, Daniel Quinlan wrote: Package: debian-policy Version: N/A The version does matter, because, as it happens, what you've got there is not the current version of policy. (I know, because I was the last one to touch that paragraph.) - gets name of standard right Change already made. - removes my name and email (I am no longer the primary maintainer) - adds mention of FHS mailing list Seems reasonable. Even though we're in freeze, I think that this change is probably justified. Here's the _actual_ current wording (from policy 3.5.6.): p The location of all installed files and directories must comply with the Filesystem Hierarchy Standard (FHS), except where doing so would violate other terms of Debian Policy. The latest version of this document can be found in the ttdebian-policy/tt package or on url id=http://www.debian.org/doc/packaging-manuals/fhs; name=FHS (Debian copy) alongside this manual or on url id=http://www.pathname.com/fhs/; name=FHS (upstream). Specific questions about following the standard may be asked on the ttdebian-devel/tt mailing list, or referred to Daniel Quinlan, the FHS coordinator, at email[EMAIL PROTECTED]/email. /p So, I suggest that a reasonable patch would be: - referred to Daniel Quinlan, the FHS coordinator, at - email[EMAIL PROTECTED]/email. + referred to the FHS mailing list (see the FHS web site + for more information). Someone should really specify the VERSION I think we discussed that at some point. I'm not sure why we decided not to do it, but since we're in a freeze, we probably should stick with what we have. But if you're no longer the contact, then I think that we do need to remove your name/email. I suppose this proposal needs a second -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#96597: changing policy requirements for debian native packages to _MUST_
On Sun, Mar 03, 2002 at 11:28:55PM -0500, Andres Salomon wrote: dh_installchangelogs (debhelper-3.4.11) currently bails if one attempts to install a non-debian changelog to /usr/share/doc/package/changelog.gz in a debian-native package. Ok. I think maybe that's a bug, but I'm willing to be proven wrong. Joey Hess has mentioned that various tools expect the changelog.gz for debian-native packages to parsable as debian-style changelogs. What tools? I would definitely say that any such tool has a bug. Given this expectation, one of two things should be done; either policy should be changed to explicitly allow multiple changelogs for debian-native packages, or explicitly disallow more than 1. Given this expectation, sure, but I *don't* give that expectation. If changelog.Debian.gz exists, that should be considered the Debian changelog. If it doesn't, then changelog.gz should be considered the Debian changelog. A tool which doesn't work this way should be considered broken, IMO. The current interpretation of it (section 13.8), for debian-native packages, reads as if the package only has 1 changelog, put it in changelog.gz. That seems reasonable, and meets my definition above (there's no changelog.Debian.gz, so changelog.gz is the Debian changelog). Note that any Debian package _must_ have a Debian changelog, so, if there's only one changelog, it must be the Debian changelog. This should be changed to something like: If the package is a debian-native package, the changelog installed in /usr/share/doc/package/changelog.gz MUST be the debian changelog. No. Current policy seems fine to me. The exact quote from the current policy is: If the package has only one changelog which is used both as the Debian changelog and the upstream one because there is no separate upstream maintainer then that changelog should usually be installed as /usr/share/doc/package/changelog.gz; if there is a separate upstream maintainer, but no upstream changelog, then the Debian changelog should still be called changelog.Debian.gz. Frankly, as far as I'm concerned, if something is a Debian-native package, it should only have one changelog. If there's any reason for maintaining two, then that probably counts as sufficient justification for NOT creating a Debian-native package! A proposal which made this into policy might have my support. The current proposal does not. In other words, I doubt if I approve of what you seem to be trying to do in the first place. Although, without more details, it's hard to be sure. In any case, the argument for the current proposal seems to be that existing tools make assumptions that do not match what policy says. Unless and until an effort to fix those tools fails, I think we should leave policy as it stands. Especially since policy has been frozen for months now. So, I guess I have two questions: 1. What are these tools that joeyh refers to, and why can't they be fixed? 2. Why the heck are you trying to make a Debian-native package with two changelogs? Without reasonable answers to both of these questions, I'm afraid I'll have to oppose the proposal. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#128734: debian-policy: criteria for Games/Puzzles is not precise enough
On Fri, Jan 11, 2002 at 02:39:27PM +0100, Yann Dirson wrote: Games/Puzzles is defined as tests of ingenuity and logic. This definition, unfortunately, includes many board games, and some board games get incorrectly classified as puzzles (eg: g5). A better definition could be given. For example: I don't think it's a major problem to have some overlap between the categories. I tend to think of board as being a category for traditional board games which have been ported to the computer. I'm not sure that g5 (my program) actually qualifies under that definition. (OTOH, I'm not sure it doesn't.) Board: games with several players, played on a board (possibly only against the computer) Technically, no computer games are played on a board -- they're played on a computer! :-) Nitpicking aside, though, if you really want to clarify things, I would say that there are other categories more worthy of attention: strategy vs. board strategy vs. simulation simulation vs. board arcade vs. tetris-like puzzles vs. toys All of these, it seems to me, have potential for ambiguity and overlap. In some cases, more than puzzles vs. board. As for the case of g5 (5-in-a-row), although I've never seen it played on a board (which is why I originally put it in Games/Puzzles), I agree that it could be played on a chess or go board, so I am willing (and planning) to move it to Games/Board. Which should resolve at least part (if not all) of the current dilemma. But as for the proposal itself, I think there's a danger in over- specification of categories here too. If the categories overlap, then someone may put a program in a less-than-optimal category, but if the categories have fixed and very distinct boundaries, then there may be cases where something doesn't fit into *any* category. Which, IMO, is a worse result than the status quo. In any case, I neither support nor oppose this proposal, but I do feel that if we're going to do something about our categories, it should be a little broader in scope. Frankly, I'm more worried about the arcade category, which is rather over-full on my system. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Non-C/C++/ObjC source files in /usr/include subdirectories
On Wed, Nov 21, 2001 at 12:38:55PM +0100, Wichert Akkerman wrote: Quoting from section 4.3 of the FHS 2.1: Which in turn suggests the proper solution: ask on the FHS lists, and maybe on ada/gnat developer lists. Try to find an answer that applies to everyone, not just to Debian, and I suspect that Debian will be more than happy to go along. How about using /usr/share/ada instead? Speaking for myself, yuck! I'd much prefer to use /usr/include for this. But I'm not an ada expert, and I don't know what the historical precedent (if any) is. Maybe we should find out how it's _supposed_ to be done before we make a final and binding decision, eh? cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#117916: debian-policy: New virtual package httpd-cgi.
On Thu, Nov 01, 2001 at 06:46:53PM +0100, Uwe Hermann wrote: I hereby propose to add a new virtual package called 'httpd-cgi' to the list of virtual packages in virtual-package-names-list.txt. This part of policy is not very clear. As I read it, you don't need to make a formal proposal for new virtual package names (or menu categories); you just have to discuss the proposal on d-policy. If nobody complains, you're in. This is, I believe, the reason that the virtual package list (and the menu tree) are kept as separate documents: so that they can be updated separately. As for the proposal itself, http-cgi seems like a reasonable name, and a reasonable virtual package. The only thing I'd ask is this be added to the daemons *before* any packages try to use it as a dependency. Get in touch with the httpd maintainers, and make sure they're ready and willing to do this, and (if no one has objected by that time) we should be go. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#115438: PROPOSAL] addition of new menu tag for kde menu removal
On Sat, Oct 13, 2001 at 12:25:10AM -0600, Ivan E. Moore II wrote: information. KDE ends up seeing 2 different sets of information for the same binary and can (and usually does) gets confused. Can you be more specific about this gets confused part? The reason I ask is that I think it's important that the Debian menus be consistent. When you switch from wm to wm, (or use other menuing systems -- I have an emacs menu-method in the works) you should still find the same apps in the same place (at least, relative to the base of the Debian hierarchy). Personally, I think that the approach taken by KDE at the moment constitutes a particularly ugly bug. A nicely overengineered bug, but a bug nonetheless. However if there are technical reasons why it has to be done that way, then I suppose there's little we can do. I'm not really sure where this should fit into policy but I assume it would go into the menu specific policy. I'd prefer it to go into a separate KDE policy (if it goes anywhere). There is ample precedence for such things (perl, emacs, etc.). -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
On Tue, Sep 04, 2001 at 08:53:20PM -0400, Steve M. Robbins wrote: --- policy.sgml.orig Sun Sep 2 22:50:21 2001 +++ policy.sgml Tue Sep 4 20:50:04 2001 @@ -3714,18 +3714,8 @@ must call prgnldconfig/prgn in its prgnpostinst/prgn script if the first argument is ttconfigure/tt and should call it in the prgnpostrm/prgn script if the first - argument is ttremove/tt. - /p - - p - However, prgnpostrm/prgn and prgnpreinst/prgn scripts - emmust not/em call prgnldconfig/prgn in the case where - the package is being upgraded (see ref id=unpackphase for - details), as prgnldconfig/prgn will see the temporary - names that prgndpkg/prgn uses for the files while it is - installing them and will make the shared library links point - to them, just before prgndpkg/prgn continues the - installation and renames the temporary files! + argument is ttremove/tt. Apart from these two circumstances, + the maintainer scripts must not call prgnldconfig/prgn. /p sect This seems like the most sensible approach to me. I would second this. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#108416: Format of short description should be mandated
On Sat, Aug 18, 2001 at 11:06:36PM -0500, Branden Robinson wrote: Well, if I downgrade my must not's to should not's, would you second the proposal? That wasn't addressed to me, but my reaction is the same as it was to the original proposal: this doesn't belong in policy. It belongs in dev-ref or the packaging manual, or some similar set of guidelines for maintainers. Policy is not required to file bugs (minor for typos, wishlist for unaestheticness) against package descriptions. All it does is allow severity escalation. Having some guidelines somewhere would be good, because it would allow us to move towards the goal of greater consistency. But I still say that policy is not the place for such guidelines. That said, here are some specific comments on details of Branden's proposal: * typically be written in a form that completes the following sentence: foo is a package which provides (a/an)... The word typically reveals the flaw here, I think. It should be unless it shouldn't be. This is clearly just a guideline, and not even a firm one, and thus, definitely doesn't belong in policy (even if other parts of the proposal are accepted). * expand acronyms [...] Generally, but not necessarily always, a good idea. IMO. I'd like to see this as a guideline. I do not want to see it made policy. Counter-example: a package named httpd shouldn't necessarily have to exand Hyper Text Transfer Protocol Daemon in the one-liner. We know. And sometimes the expansion of an acronym is a humorous afterthought: Little Instructive New Unixlike Xystem :-) * not attempt to explain or describe things to the user that he or she would most likely already know if he or she wanted to install it (For instance, most people who care anything about python or perl packages know that these are scripting languages [...] Here I strongly disagree. I think the one line description should be targetted at people who _don't_ have any idea what the package is. [should not] repeat the package name [...] Hmm, if any part of this proposal belongs in policy, it's this. But I still think a guideline is sufficient. [should not] refer to the names of other packages, protocols, [etc.] in their canonical forms. A) I think this is backwards (typo, no doubt), and B) doesn't deserve to be more than a guideline. (Plus, I loathe l33t mixed-case names like PostScript and NeXT, and I don't care if it's canonical or not!) Furthermore, what about things like MUA? Arguable a canonical form, but I don't think it belongs in a short description. [should not] use indefinite articles where not necessary. Yuck. I'm not even sure this belongs in guidelines. [should not] use abbreviations Piffle! I'm not going to spell out etcetera. [must not] be identical to the short description of another package. I think that _related_ packages should not have identical short descriptions (e.g. gcc, xemacs), but if two unrelated packages end up with identical short descriptions, I'm not sure it'll kill us. (e.g. graphical mail reader using GTK+ toolkit.) [must not] be longer than 80 chars. Finally something I agree with! :-) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#109182: Removing more historical cruft
On Sun, Aug 19, 2001 at 02:15:40PM -0300, Cesar Eduardo Barros wrote: This proposal was not about traceroute. It was about everything else Oh yes, very tricky. This subterfuge had us all fooled. Bah! -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#108416: Format of short description should be mandated
On Sat, Aug 11, 2001 at 10:52:55PM +0200, Sebastian Rittau wrote: On Sat, Aug 11, 2001 at 04:35:42PM -0400, Ben Collins wrote: I also think that that short description should be as close as possible to a real sentence. Agreed. Thatswhy I prefer the period. :) I strongly disagree. Most packages have a noun clause as the first line of the description, not a sentence, and thus, capitalization and a period would be grammatically incorrect. This could, of course, be changed by mandating that the first line _be_ a sentence, but it would gain us nothing except redundancy and awkwardness in most cases. Thus: Package: foo-ed Description: editor for foo files vs. Package: foo-ed Description: Foo-ed is an editor for foo files. The former is more concise, and every bit as clear. Plus, it avoids the awkward situation here where you end up capitalizing the package name, even though the package name on the file system (and in the database) is lower-case. Of course, there may be cases where it makes sense to use a full sentence in the first line of the description. For this reason, IMO, we should neither forbid nor mandate capitalization and periods. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
