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]
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" or"x11". 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]
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
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]
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 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
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]
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 -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 -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]
Bug#314808: Incorrect directory for web applications.
On Mon, Jun 20, 2005 at 12:39:12AM +0100, Julian Gilbey wrote: > On Mon, Jun 20, 2005 at 12:03:01AM +0200, Miguel Gea Milvaques wrote: > > > Also, as this is a draft, the useage of "/usr/share/PACKAGE/www" may > > > change. IMO, it's probably not going to, but it may be worth keeping > > > (main) policy as is until we are in a position to release 1.0 of the > > > WebApps policy. > > > > No problem for me. But It could give little problems. On one of my > > machines a was beholden to remove /usr/share/doc directory, it broke my > > ldap-account-manager installation. > > Note: /usr/share/PACKAGE/www, not /usr/share/doc/PACKAGE/www. > Removing /usr/share/doc should not impact this web suggestion. And what happens if my WebApp package is named "doc"? Or "applnk"? Or "keymaps" or "locale" or "pixmaps" or "zoneinfo"? While /usr/share/* is not the world's most overloaded namespace, its overloaded enough to cause me some concern, and if there are any reasonable alternatives (and I think there are), I would recommend using one instead. -- 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#294351: Please extend 9.4's ellipsis style requirement tocover maintainer scripts and dpkg
On Mon, Feb 14, 2005 at 11:20:19AM +, [EMAIL PROTECTED] wrote: > No shenanigans here. The dpkg maintainer says that he wants guidance > from policy. 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. > He wrote: > Actually my position is that if harmonisation of output > during install/upgrade is to occur, it should be mandated > by policy. Hmm. That's a very peculiar thing for him to say. Perhaps you should ask him why he said that, when the general opinion on the policy list seems to be that this is not at all a matter for policy, and he is free to "harmonize" or not, at his discretion. I can think of three possible reasons he said that: 1. He misunderstands the purpose and scope of policy, 2. He was trying to give you a polite brush-off by setting you an impossible task, or 3. He misunderstood what you were asking for. And that is why I think you should ask for more information - to see which of those three reasons is correct (or if there's some other reason I've overlooked). I tend to think the second reason is most likely, but perhaps I'm judging too harshly. > No my complaint is the one I voiced, that the Debian of today can be > bureaucratic. Making simple changes can sometimes be an > unnecessarily long and disagreeable process. This is exacerbated by people who hide behind the bureaucracy to avoid making decisions they are capable, competent and qualified to make. Few, if any, of us want to or enjoy playing bureaucrat, and thus, you shouldn't be surprised when there is a refusal to decide what color of t-shirt you or the dpkg maintainer should wear, or where you should put the newlines in your own programs' output. -- 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
Bug#162120: Support #162120
On Tue, Jul 08, 2003 at 06:29:33PM +0200, Thomas Hood wrote: > Second, propose a change to policy such that it explicitly > forbid the recreation of configuration files that the admin has > deleted. This idea was rejected by AJT before and presumably > will be again. However, you might be able to get the proposal > accepted. Some packages may require a config file, in which case, I think they would be justified in recreating it. Others may use the presence or absence of a file as a flag, in which case, it's important not to recreate it. How about, instead of trying to force all packages into a narrow mold, which may or may not be a comfortable fit in some cases, we require *documentation* for config files. Or, at the least, pick a default behavior and require documentation for packages which don't follow that default. Frankly, I would love it if I could see a file in /etc, and could know that typing "man 5 filename" will tell me what that file is and how it works. That may be optimistic, but it sure would be nice. -- 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
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
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 @@ > > tests of ingenuity and logic > > + Simulation > + > + real world simulations, like flight simulators > + > Sports > > games derived from "real world" sports 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
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 @@ > > text editors, word processors > > + Educational > + > + educational and training programs > + > Emulators > > wine, dosemu, etc. > > 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
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: 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: 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: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
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
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 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
(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 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
Re: Bug#178251: slang: don't do a dh_testroot in clean
On Mon, Mar 17, 2003 at 10:32:58PM -0500, Anthony DeRobertis wrote: > If the consensus is that having clean not require root (except > in those two cases mentioned in policy) is a good thing [...] I think things are fine the way they are, I think what you're suggesting would be a lot of work, I see no tangible benefits, therefore I oppose the idea. -- 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 Thu, Mar 13, 2003 at 10:43:42AM -0600, Drew Scott Daniels wrote: > On Thu, 13 Mar 2003, Chris Waters wrote: > > 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.) > An exaggeration to get attention. Yes, well, that may have been your intent, but it's so silly that it makes it hard to take you seriously. And it also gives the impression that you're trying to make fun of the people who wrote the original, which isn't very nice. (I know now that you weren't trying to make fun of anyone, but that's the impression I had at first.) > My only question being, what about packages that don't directly use > standard IO, but call an intermediate program? Does this program have to > correspond to the Debian Configuration Management Specification? I think we can apply the "a difference that makes no difference is no difference" rule here - if you use standard IO, does it make a difference whether you use it directly, or through an intermediate program that in turn uses standard IO? I think the answer is pretty clearly no. If you can show a way that it would matter, then we can try to clarify this, but otherwise, I think it's moot. Keep in mind that policy is intended to help us make a better system, not to allow the filing of whimsical bug reports. > [...] intermediates such as ncurses, slang (I'm not sure if it could > be an intermediate) do not seem to conform to it and would not be > allowable. Yes, that is exactly the intent. > I think this is a desirable meaning, but I'm unsure as to how many > serious bugs this may cause. Most likely none. Before debconf appeared, the rule was standard IO only. So anything else would have long since been fixed. > It would be interesting to find out how many packages use direct IO > and methods other than debconf if there are any that still don't use > debconf. Yes it would. I would definitely like to drop the standard IO rule, and mandate debconf-equivalents. But we have a ways to go still before that becomes practical. > Also if I did find the correct document, then it'd be nice to change the > word "Specification" to "Protocol" and/or put in a link to the document. Um, there is a link further down in the same paragraph. -- 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 @@
Prompting in maintainer scripts
Package maintainer scripts may prompt the user if
- necessary. 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. 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
+ debconf - which conforms to the Debian
+ Configuration Management Specification, version 2 or
+ higher. These are included in the
debconf_specification files in the
debian-policy 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
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: > restart > - stop and restart the service, > + stop and restart the service if the service is already > running, otherwise start the service, > > reload 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 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
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 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 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] 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: [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 Sun, Dec 08, 2002 at 05:08:20PM -0600, Adam DiCarlo wrote: > For now, I was planning on recommending something like this: > We recommend that you add the upstream author's name, email address, > and the URL for the package's homepage to the package description in > debian/control. It should be added at the end of description, using > the following format: Some authors may not WANT their email in the package description. At least one of my upstreams would probably shoot me if I tried that. (Even on his own web page, his address is only available as a GIF.) IMO, any "best practices" recommendation should recommend NOT posting ANYONE'S email address in any public place unless the owner of the address has OK'd it. > Author: Norman Walsh <[EMAIL PROTECTED]> "Author" is a bit of a misnomer. There may be a team of authors, and/or the actual author may no longer be the upstream maintainer. > Homepage: http://docbook.sourceforge.net/ Ditto for this: some packages may have only an ftp: URI, which doesn't exactly qualify as a "homepage", IMO. But my objections to this are much milder. -- 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 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 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 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 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 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. > > > - > - 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 - name="undocumented" section="7"> manual page may be > - provided. This symbolic link can be created from > - debian/rules like this: > - > -ln -s ../man7/undocumented.7.gz \ > - debian/tmp/usr/share/man/man[1-9]/requested_manpage.[1-9].gz > - > - 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. > + > + 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. > + > + It is not very hard to write a man page. See the + id="http://www.schweikhardt.net/man_page_howto.html"; > + name="Man-Page-HOWTO">, man(7), the examples > + created by debmake or dh_make, or the > + directory /usr/share/doc/man-db/examples. > + > + > + > > > 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#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
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#164035: debian-policy: [PROPOSAL] build-dependencies should be satisfied during the clean target
On Thu, Oct 10, 2002 at 12:44:52AM +0100, Andrew Suffield wrote: > This is basically an attempt to ratify the current practice of using > debhelper in the clean target. Currently, policy does not require > debhelper to be installed when the clean target is run, even though it > is in the build-depends field; [...] [so we need to add "clean"] Sounds like a simple oversight, I second this proposal. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku pgp1pVg84NXCv.pgp Description: PGP signature
/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.d),
>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- 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 + 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 on their own 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 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: [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]
Whoops, I intended that last reply to go to the list. Just shows that you should check your headers even when you're writing a quick note. :) On Mon, Jul 29, 2002 at 01:59:19PM +0200, Wichert Akkerman wrote: > Previously Chris Waters wrote: > > Yes, and those virtual packages with no associated interface tend to > > be less useful. I completely agree. I still think it's a bit much to > > throw them out, just because they're not _as_ useful as the rest of > > the virtual packages. > I never said we should thrown them out.. Not directly, no, but you said that "A virtual package is a means to indicate a package provides a certain interface, not some functionality. Functionality is useless if you can't use it in a standard way." If the merely-functional virtual packages were actually useless (which is essentially what you said), then I think we would be justified in throwing them out. But I don't think they are, so I don't think we are. -- 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: /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]
Bug#152965: debian-policy: menu policy has outdated address for me
Package: debian-policy
Version: 3.5.6.1
Severity: minor
Tags: patch
The file menu-policy.sgml has an out-of-date email address for me.
I've attached a quick patch for this.
--- menu-policy.sgml~ Sun Jul 14 13:52:59 2002
+++ menu-policy.sgmlSun Jul 14 13:53:41 2002
@@ -22,7 +22,7 @@
The Debian Menu sub-policy
Chris Waters
- [EMAIL PROTECTED]
+ [EMAIL PROTECTED]
Joey Hess
-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux starless 2.4.14 #1 Fri Nov 16 00:46:36 PST 2001 i686
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages debian-policy depends on:
ii fileutils 4.1.9-3GNU file management utilities
-- no debconf information
--
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: is a(n) 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.): 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 debian-policy package or on http://www.debian.org/doc/packaging-manuals/fhs"; name="FHS (Debian copy)"> alongside this manual or on http://www.pathname.com/fhs/"; name="FHS (upstream)">. Specific questions about following the standard may be asked on the debian-devel mailing list, or referred to Daniel Quinlan, the FHS coordinator, at [EMAIL PROTECTED]. So, I suggest that a reasonable patch would be: - referred to Daniel Quinlan, the FHS coordinator, at - [EMAIL PROTECTED]. + referred to the FHS mailing list (see the FHS web site + for more information). > Someone should really specify the 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
