Re: Bug#88029: Package which uses jam (instead make)
On 19-Oct-03, 04:20 (CDT), Josip Rodin [EMAIL PROTECTED] wrote: But it's a historic injustice, Help! Help! I'm being repressed! The Man is keeping me down! Up with perl, down with make! Power to the people! Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#88029: Package which uses jam (instead make)
On 19-Oct-03, 13:03 (CDT), Josip Rodin [EMAIL PROTECTED] wrote: On Sun, Oct 19, 2003 at 11:50:41AM -0500, Steve Greenland wrote: But it's a historic injustice, Help! Help! I'm being repressed! The Man is keeping me down! Up with perl, down with make! Power to the people! We share an enthusiasm for overloaded phrases, I see :) but a small verbal blunder doesn't invalidate the issue at hand. No, it doesn't, but it doesn't validate it either. I've yet to see a technical argument for allowing debian/rules to be a non-makefile. If you really want to write the script in a different format, it's trivial to meet the letter of Policy: #!/usr/bin/make -f % : debian/my_rules.py $@ That I've never seen such done (in my admittedly limited and random selection of packages to build by hand at various times) suggests that there's not much practical demand. Whenever it's come up, it seems to be someone trying to prove a point, rather than a technical need. Perhaps those who think alternative debian/rules should be allowed should implement the above, and see what breaks and what complaints it generates. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: docs, docs, and more docs(names of packages and location of files)
On 15-Jan-03, 08:58 (CST), Josip Rodin [EMAIL PROTECTED] wrote: On Tue, Jan 14, 2003 at 07:54:58PM -0600, Adam Heath wrote: Also, there is the problem that some docs depend on their foo.deb, others don't. Since it's reasonable to expect that some people will just want to install a -doc package to read the docs e.g. on a machine where their PDF viewer works better or works at all, the dependency should be a Recommends or Suggests. Why any dependency relationship at all? If I'm installing foo-doc, it's reasonable to assume that I can figure out whether or not I want to install foo on my own. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: [devel-ref] author/homepage in description
On 16-Dec-02, 11:47 (CST), Josip Rodin [EMAIL PROTECTED] wrote: (Besides, that calculation assumes things like all developers doing it and all packages having it.) That's probably a reasonable assumption. As soon as such a field exists, some enterprising young person will generate wishlist bug reports against every package in the archive that doesn't have them, and since it's a reasonable request, probably the next upload will have a field. Even packages that don't have a useful homepage will have to put something like Homepage: N/A to prevent repeated stupid bugreports. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
On 13-Nov-02, 15:22 (CST), Britton [EMAIL PROTECTED] wrote: I have some reservations about this. Along with potential false hopes during load time, the undocumented page provides pointers to places where documentation may be found. It may be irritating to people in the know, but since man is still the most widely known unix documentation interface, new users may be helped by these pointers. Colin already volunteered to hack man to provide the pointers instead of a simple 'manpage not found'. Next! Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: RFD: Essential packages, /, and /usr
I know I'm going to hate getting into this one, but: On 21-Jun-02, 14:31 (CDT), Clint Adams [EMAIL PROTECTED] wrote: (2) There's no benefit to anyone using a shell other than ash or bash as /bin/sh on a Debian system. No, you're being deliberately obtuse on this one. Clint, Anthony has asked several times on this thread for you to state the benefit of being able to use shells other than bash and ash as /bin/sh. The only answer I've seen is the continued chanting of POSIX is good, and I don't buy the idea of standards compliance for it's own sake. I understand the alleged benefits of ash (small, loads faster on a slow/small memory machine). Why would I, Debian user, benefit from being able to run pdksh as /bin/sh? (Remembering that standards compliance, in and of itself, does not give me a sexual thrill.) Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#150456: coherency with mkfs and fsck filesystem package names
On 19-Jun-02, 05:21 (CDT), Robert Millan [EMAIL PROTECTED] wrote: Package: debian-policy Version: 3.5.6.1 Severity: wishlist Taking a look at packages in Debian that contain filesystem maintainance utilities (mkfs and fsck): e2fsprogs reiserfsprogs dosfstools xfsprogs jfsutils I think it'd be a good thing if Policy suggested to use a commonly agreed naming scheme (without necessarily enforcing it). Ack. No, this not something that needs to be policy, as it has no affect on the interoperation of the packages and programs on the system. The names are probably the upstream names, and it's much better to match that, so that when documents say build jfsutils then Debian users can just translate to apt-get install jfsutils. Manoj, AJ: See? I don't think everything needs to be in policy :-) Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On 17-Jun-02, 21:51 (CDT), Anthony Towns aj@azure.humbug.org.au wrote: It seems sloppy is a pretty poor argument for moving every binary not specifically mentioned in the FHS into /usr and gratuitously breaking any scripts that needed them where they are. Yes, that would be a pretty poor argument, if I had indeed suggested doing that. But I didn't. I haven't made any suggestions about moving anything. All I've suggested is that we list what early running code can rely on, and a couple of different ways to get there. Are you sloppy when you exercise your judgement about your packages? Why would you expect everyone else to be? I don't. However, we already have cases of specific developers being, shall we say, difficult. Not sloppy, but having very strong opinions about how a particular thing should be done, despite a large number of other experienced developers disagreeing. What is the purpose of Debian Policy? I always thought it was a way to decide/document choices, when more than one choice was reasonable, and when that choice affected other developers and our users. This subject falls into that definition, in my opinion. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On 16-Jun-02, 15:30 (CDT), Chris Waters [EMAIL PROTECTED] wrote: 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. I wasn't discussing any particular command, and Manoj didn't mention the FHS. I think if we (Debian) said Early running init scripts can count on the FHS required commands being in /bin:/sbin, and anything else might be in /usr/bin:/usr/sbin, then Branden and I would be satisfied: at least we would know where we stand. Manoj and Anthony have argued (to my understanding) that the current situation of Early running init scripts can on on whatever the maintainers feel like putting in /bin:/sbin is acceptable. To me, it seems sloppy. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On 16-Jun-02, 22:04 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: Having an explicit, separate documentation of technical things that has to be maintained, or else it slips out of synchronization with reality, is certainly not to be preferred to haveing a deterministic way of inferring such information. But it's not a reliable prediction. It's simply a repoort on the present situation. There's nothing to prevent things from being moved out of /bin (except those subject to the FHS). Additionally, a list of these tools are guaranteed to be available before /usr is mounted is not the same as a list of these are the tools from Essential packages that are in /bin:/sbin, and need not be particularly fluid. In other words, Branden's simple shell snippet is the documented list. I seem to be missing the reason why that is not good enough. 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). Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On 16-Jun-02, 12:55 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: (Superfluous how? just look at the contents of /bin and /sbin to determine whether to command is actually available that early in boot). 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. If I object, there's nothing to keep them from saying tough. I'd like to think that no developer managing a Essential package would do so, but I don't think it's impossible, either. to be yet-another-stick-to-beat-recalcitrant-developers-with. Sigh. The policy is not a stick mantra is now being used to justify not listing something that it makes perfect sense to list: which tools are guaranteed to be available at what stage in the boot process. I don't care if that list is set at the current intersection of Essential and /bin:/sbin, as one can always work around any particular missing tool (or, if not, then we need to make sure that tool gets moved). Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#146023: suggested patch against policy, documenting libexec, or current custom on use of lib for binaries in lib* packages
On 09-May-02, 13:53 (CDT), Josip Rodin [EMAIL PROTECTED] wrote: How about simply: pIf your package includes run-time support programs that don't need to be invoked manually by the users, or named in a way that would cause conflicts if placed in tt$PATH/tt, but are nevertheless required for - the package to function, you should place them in a subdirectory of - file/usr/lib/file./p + the package to function, you should place them in a subdirectory named + file/usr/lib/pkgname/file./p ...a subdirectory of /usr/lib/ leaves to much to chance, not out of malicious intent, but something on the order of Hey, I need a place to put this extra perl script, hmmm, /usr/lib/perl5 looks good! Steve -- Steve Greenland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On 09-May-02, 12:48 (CDT), Anthony Towns aj@azure.humbug.org.au wrote: On Mon, May 06, 2002 at 06:11:46PM +0100, Julian Gilbey wrote: My suggestion for a policy rewrite it to move to the standard RFC uses of MUST and SHOULD, and indication RC-ness in an orthogonal way. In short, this isn't going to happen. Which this in this isn't going to happen? This as in use RFC definitions of MUST and SHOULD, or this as in the policy document include RC-ness? I think changing policy to use proper MUST and SHOULD would help clarify, and the RFC uses are widely understood, and the current situation of them being similar but not identical is confusing to (Debian) newcomers. However, since (as you've noted) RCness ends up being the decision of the Release Manager anyway, putting it in the policy doc is a Bad Thing. I'm guessing from the rest of your paragraph that we're not disagreeing, but it was not completely clear to me. -- Steve Greenland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The meaning of must not modify wrt. passwd, shadow etc.
On 24-Dec-01, 07:14 (CST), Ben Armstrong [EMAIL PROTECTED] wrote: Please CC me on all replies as I am not subscribed to this list. In Debian Policy 3.5.6.0 section 10.2.1 it says: Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow. This is followed by a discussion about how packages can modify these files using adduser. What does modify mean in this context. Is it really provide, replace, or overwrite? I believe this note should be clearer. The intent is that other packages not modify those files _except_ through the approved interface of add-user. No sed, awk, perl, etc. The current wording could be clarified. Steve
Bug#48045: normal and non-US names
On 20-Sep-01, 11:28 (CDT), Glenn McGrath [EMAIL PROTECTED] wrote: [rant deleted] Hmmph. And they say Debian is not a political organization. Anyway, this bug should be closed as it is not a properly formed policy proposal. Steve, who understands and somewhat agrees with the sentiment, although not the proposal. -- Steve Greenland [EMAIL PROTECTED]
Bug#112828: Example for using update-alternatives in package maintainer scripts
On 19-Sep-01, 13:06 (CDT), Stefan Hornburg (Racke) [EMAIL PROTECTED] wrote: Please include an example how to use update-alternatives in the Debian policy. Even reading the manpage left me without a clue how to fix #112620, because I don't know how update-alternatives is called the right way. While I share your pain, it's not a policy issue, but should go into the Developers Guide when that gets redone. Steve -- Steve Greenland [EMAIL PROTECTED]
Bug#112090: PROPOSAL]: support reduced footprint debs at build time]
On 17-Sep-01, 13:47 (CDT), David Kimdon [EMAIL PROTECTED] wrote: I see that we have a situation where we have created some specialized handling of certain packages. If we can find a way to generalize that handling so that it will be useful to more people I'd call that a win. That is what I am proposing. Not all problems require a general solution. There are a few packages (relative to the total size of the debian archive) that need special versions for use with the installation system. What is the value of a embedded version of TeX, for example? Spending the non-trivial time/thought to generalize this for a (IMO) very small gain seems like a misguided effort. And I don't believe that they would generalize to an embedded Debian, either. Embedded systems tend to target specific purposes, with specific requirements, and each would probably make different choices about what particular options/features/chunks of the package they would choose. Steve -- Steve Greenland [EMAIL PROTECTED]
Re: Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
On 06-Sep-01, 06:59 (CDT), Herbert Xu [EMAIL PROTECTED] wrote: BTW, what is it with all the Steves in this thread? :) Is your problem that there are so many of us, or that we seem to be excessively dim? I personally blame insufficient caffiene... Steve Greenland (No offense intended to Mr. Robbins -- add smileys as desired.)
Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
On 05-Sep-01, 16:52 (CDT), Herbert Xu [EMAIL PROTECTED] wrote: Vociferous Mole [EMAIL PROTECTED] wrote: So? Isn't it a bug? This isn't a case of a policy change creating a bug, but of a existing bug being highlighted by the policy clarification. It doesn't break anything, so it's not a bug. I thought we just established that calling ldconfig during 'postinst upgrade' is wrong. Therefore, all packages simply doing a ldconfig in their postinst (as you wrote, and which I interpreted as without checking their arguments) are doing the wrong thing during an upgrade. If that is not what you meant, please clarify. I don't see how the proposed change causes a problem for packages that aren't already doing calling ldconfig inappropriately. Steve
Re: Software Licenced Under a Specific Version of GPL
On 31-Aug-01, 16:22 (CDT), Santiago Vila [EMAIL PROTECTED] wrote: Let's consider the following proposal: The GPL file in base-files should better be renamed to GPL-2 and GPL should be a symlink pointing to it. [ The proposal is independent of whatever step may come afterwards if/once it is implemented ]. I will gladly implement it if it gets the approval of the policy group, which, for this particular proposal, I understand it as three seconders (since I'm not proposing it myself) and no objections. I second this, although since it's not really a policy decision it doesn't really need group approval. Steve
Re: Software Licenced Under a Specific Version of GPL
On 31-Aug-01, 10:43 (CDT), Santiago Vila [EMAIL PROTECTED] wrote: On Fri, 31 Aug 2001, Andrew McMillan wrote: To make it happen you should file a wishlist bug against the package which provides the GPL, asking it to provide it as a versioned file and symlink /usr/share/common-licenses/GPL to the most recent version. As of today, there is only one GPL file. In my opinion it's soon for that. However, if you insist that this has to be done now, then please get policy changed first. For example: No, we change practice first, then policy. The file as to be there before policy can tell other packages to use it. If we create GPL2 and GPL-GPL2, then no package will be out of policy compliance (or at no more so than before). packages under `GPL or later' should refer to the latest GPL version which is always at [current location], packages under a specific version of GPL should refer to the exact license under /usr/share/common-licenses if it still exists, or include the complete text of the GPL version under which they are distributed if it does no longer exists I don't think we should remove any licenses from common-licenses. Even if we can show that no current packages refer to the obsolete version, we can't force people to upgrade from older packages, or deal with external packages at all. So I'd object to the bit about if it still exists Steve
Re: Software Licenced Under a Specific Version of GPL
On 30-Aug-01, 03:12 (CDT), Ari Makela [EMAIL PROTECTED] wrote: I don't like the idea of licencing my software under a licence I cannot know because it doesn't even exist so I tend to use GPL version 2. So should I just ignore the error message or should there be file /usr/share/common-licenses/GPL-2? Put in your packages copyright file something like: This package is covered by the GPL v2. That file should be available as /usr/share/common-licenses/GPL. If that file not there, or is not version 2 of the GPL, please write [EMAIL PROTECTED] for a copy of the correct license. (Or put a web address, or refer to the FSF website, or somesuch.) Hopefully, when Debian starts including GPL v3, we'll name /u/s/c-l/GPL3, and leave GPL v2 where it is. Steve
Bug#108416: Format of short description should be mandated
On 22-Aug-01, 12:30 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: I find this assertion in tension with the one you make later that the one line description should be targetted at people who _don't_ have any idea what the package is. Why would such people know what HTTP stands for? I think httpd would be a lousy name for a package, given that we have more than one such tool in Debian, but if there were one called xtifr-httpd, I don't think Chris Waters' Hypertext Transfer Protocol Daemon would be a bad short description. I tend to agree in general, but in the specific case of HTTP daemons, if you don't know what an httpd is, you probably don't need one, and seeing hypertext Transfer Protocol Daemon isn't going to help. OTOH (On The Other Hand, HTH), Chris Waters' Web Server is better than either. Expanding MP3 Player seems silly. All of which leads me to believe that expansion of acronyms should be left to the long description. If there's a problem with a particular one, well, that's what the BTS is for. And I think there are cases where you simply can't educate people sufficiently in 80 characters to enable them to make an informed decision. Exactly. Steve
Bug#108416: Format of short description should be mandated
(Sorry to come in late and revive this; I was out of town.) Since there doesn't seem to be consensus on this topic, I thought I'd weigh in with my opinion (worth every cent you paid for it). I like most of Branden's proposals/points/guidelines, but none[1] of them belong in policy. This is the beginning of the creep into over specification. The contents of a short description have no effect on the operation of the user's system, or interaction with other packages, etc. The problems with short (and long) descriptions are almost entirely content problems, not format problems, and better served by an individual bug reports with a suggested improvement. I *do* think that whoever is maintaining how to make debian packages tutorials would be well advised to include or reference Branden's write up, though. Except for one thing: On 11-Aug-01, 18:56 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: A package's short description should not: [snip] 2. refer to the names of any other software packages, protocl names, standards, or specifications in their canonical forms (if one exists) This should be in the A package's short description should: section, right? Or include the word except between specifications and in. And protocol is misspelled. Steve [1] With the possible exception of the should be less than 80 characters clause. -- Steve Greenland [EMAIL PROTECTED]
Bug#100631: Changing to ammendment
severity 100631 normal retitle 100631 [AMMENDMENT 28/06/2001] Restrict http access to /usr/share/doc bye This proposal has two seconds and no ammendments. Since it has generated no controversy, I'm setting the discussion period of 10 days, which will end on 8 July 2001. Thanks, Steve -- Steve Greenland [EMAIL PROTECTED] pgpSZ0TCn2f71.pgp Description: PGP signature
Re: Resolving policy and practice wrt sbin directories (traceroute)
On 26-Jun-01, 23:02 (CDT), Rene Weber [EMAIL PROTECTED] wrote: Do we really mean must for FHS compatibility if we are advocating ignoring its directives for the sbin directories? Will you *please* stop harping on this? A substantial percentage of us think we *are* following the FHS w.r.t. sbin and traceroute. You don't agree, that's fine, but please stop making this statement as if your opinion is unarguable fact. I personally don't *care* where the actual binary is, so long as it is accessible via /usr/sbin/traceroute (because removing that *will* break things, as has been explained multiple times). The point is that the FHS, *as published* (v2.2), says nothing specific about traceroute. Any private communications you have had with FHS developers are irrelevant to Debian Policy unless and until the FHS is modified. If and when that happens, I will support you 100% in getting the binary moved (so long as the link in /usr/sbin remains). In the meantime, the package maintainer believes that traceroute is an administrator program, and belongs in /usr/sbin. That is his perogative: see the constitution. If your response to that is But he's in violation of the FHS, please go back and re-read the preceding paragraph. Steve -- [EMAIL PROTECTED]
Bug#36151: Clearing out old policy proposals
On 27-Jun-01, 07:09 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: Agreed. So should we close this bug report? Yes, please. Steve -- Steve Greenland [EMAIL PROTECTED]
Bug#36151: Clearing out old policy proposals
On 23-Jun-01, 17:36 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: On Fri, Jun 22, 2001 at 09:08:10AM -0500, Steve Greenland wrote: On 21-Jun-01, 17:33 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: Scripts which use programs in a directory other than /usr/bin and /bin (and /usr/bin/X11?) should append that directory to the PATH I'd really like to see the list expanded to include /sbin and /usr/sbin as well. My rationale is that init.d scripts are intended (and mostly Please see the original proposal: the problem was precisely that there were situations where these directories were not in the PATH and this broke the scripts. Yes, and those situations are caused by the sysadmin changing the default path setups and removing /sbin and /usr/sbin from the default root user path i.e. they have gone out of their way to break it. We should not write policy to allow people to screw up their systems. If we are going to accommodate people who remove /sbin and /usr/sbin, why shouldn't we accommodate those who remove /usr/bin and /bin as well? The correct response to a bug report that an init.d script doesn't run with /sbin:/usr/sbin in the caller's path is Why are you running it from a user account? When the reporter says I'm not, I'm logged in as root the reply is Then put your path back the way it belongs. Steve -- Steve Greenland [EMAIL PROTECTED]
Bug#36151: Clearing out old policy proposals
On 21-Jun-01, 17:33 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: Scripts which use programs in a directory other than /usr/bin and /bin (and /usr/bin/X11?) should append that directory to the PATH I'd really like to see the list expanded to include /sbin and /usr/sbin as well. My rationale is that init.d scripts are intended (and mostly only useful) for the root user, and the the whole point of /sbin and /usr/sbin is to contain scripts useful for the root user. It is completely reasonable to assume that those directories are in the path, and my opinion is that if they aren't, the admin needs to fix their system. (Yes, this is the same argument from debian-devel when we had this discussion originally. The counter-argument is to protect the admin from making a dumb mistake. The counter-counter-argument is that an admin who can't manage to keep a sane path in the root account needs to be running MacOS, not Linux. Please proceed from here.) As a particular point, note that if they are not considered standard, most init.d scripts will have to be modified add them to the path, as start-stop-daemon is in /sbin. Steve -- Steve Greenland [EMAIL PROTECTED]
Bug#23661: Bug #23661:
This note is being sent as part of a project to clean out old ( 1yr) debian-policy proposals. If you disagree with action below please respond to [EMAIL PROTECTED], not to me, so that the discussion may be carried out publically in debian-policy. Feel free to re-open the bug while it's being discussed -- I'm not trying to force any particular disposition, just taking my best shot at resolving dead issues. Bug#23661: usr/doc should not be accessible through http servers by default Summary: suggests that http://hostname/doc/ not be available by default, except to localhost clients. security through obscurity argument raised, but consensus seemed to be that making ones entired installed program list, including version, available to the internet was perhaps pushing it a bit far. It was noted that later releases of Apache and Boa restricted access, but that doesn't solve the problem generally.It then went on to the Well, there's a whole bunch of services that shouldn't be available by default. Raul Miller seems to have started examining a way to deal with this, but there's no further note in the BTS after 22 Jun 2000. Discussion: Policy currently says HTML documents...can be referred to as http://localhost/doc/package/filename;. This could be sufficient to imply that access should, by default, be restricted to localhost, but a guiding comment or footnote should probably be added. One question is what to do about httpds that don't support access controls. Action: I've submitted a new proposal that addresses only the httpd issue that refers to this one.
Bug#27205: Bug #27205:
This note is being sent as part of a project to clean out old ( 1yr) debian-policy proposals. If you disagree with action below please respond to [EMAIL PROTECTED], not to me, so that the discussion may be carried out publically in debian-policy. Feel free to re-open the bug while it's being discussed -- I'm not trying to force any particular disposition, just taking my best shot at resolving dead issues. Bug#27205: Daemons should run as root only if really needed Summary: See title. Consensus was that this should part of the (as yet unwritten) Debian Coding Guidelines rather than policy. Discussion: None Action: No change in status. It's being left open as a reminder.
Bug#36151: Bug #36151:
This note is being sent as part of a project to clean out old ( 1yr) debian-policy proposals. If you disagree with action below please respond to [EMAIL PROTECTED], not to me, so that the discussion may be carried out publically in debian-policy. Feel free to re-open the bug while it's being discussed -- I'm not trying to force any particular disposition, just taking my best shot at resolving dead issues. Bug#36151: etc/init.d scripts should specify an explicit PATH Summary: init.d scripts shouldn't depend on having PATH set in a useful manner -- they should explicitly set the PATH. Not much discussion in the bug logs, and most of the flame^H^H^H^H^Hdiscussion took place on debian-devel. Result inconclusive. Last few notes in BTS are that it should be part of the coding guidelines, not policy Discussion: No additional comments Action: Retitle as GUIDELINE for future reminder.
Bug#42870: Bug #42870: every alternative should be usable
This note is being sent as part of a project to clean out old ( 1yr) debian-policy proposals. If you disagree with action below please respond to [EMAIL PROTECTED], not to me, so that the discussion may be carried out publically in debian-policy. Feel free to re-open the bug while it's being discussed -- I'm not trying to force any particular disposition, just taking my best shot at resolving dead issues. Bug #42870: every alternative should be usable Summary: Packages that provide alternatives shouldn't hide the actual program off in /usr/lib or somesuch. No comments or discussion Discussion: This seems eminently sensible, but not really appropriate for policy. Action: Retitle as a [GUIDELINE] for future reference
Bug#43724: Bug #43724: experimental patch for very much faster dpkg -R
This note is being sent as part of a project to clean out old ( 1yr) debian-policy proposals. If you disagree with action below please respond to [EMAIL PROTECTED], not to me, so that the discussion may be carried out publically in debian-policy. Feel free to re-open the bug while it's being discussed -- I'm not trying to force any particular disposition, just taking my best shot at resolving dead issues. Bug #43724: experimental patch for very much faster dpkg -R Summary: A patch for dpkg to speed up disk based installs requires that version numbers be distinct, even ignoring epoch (e.g. 1:1.0-1 and 1.0-1 were not allowed.) Discussion: Wichert says this patch never made into dpkg, and given the current state of apt and dpkg development, won't be used. Action: close
Cleaning out old proposals
This is a summary of the status and disposition of many of the old ( 1yr) debian-policy proposals. Only bugs marked as fixed were considered; they were marked this way because they had been rejected or hadn't had any action in several months (stalled). If you disagree with my action, please comment and suggest an alternative. If desired, re-open the bug while we discuss. Each individual item has also been sent to the corresponding bug # in the BTS. Please don't respond to this report; instead, reply to the [EMAIL PROTECTED] address so that the history of the discussion is incorporated into the BTS. Bug #23661: usr/doc should not be accessible through http servers by default Summary: suggests that http://hostname/doc/ not be available by default, except to localhost clients. security through obscurity argument raised, but consensus seemed to be that making ones entire installed program list, including version, available to the Internet was perhaps pushing it a bit far. It was noted that later releases of Apache and Boa restricted access, but that doesn't solve the problem generally.It then went on to the Well, there's a whole bunch of services that shouldn't be available by default. Raul Miller seems to have started examining a way to deal with this, but there's no further note in the BTS after 22 Jun 2000. Discussion: Policy currently says HTML documents...can be referred to as http://localhost/doc/package/filename;. This could be sufficient to imply that access should, by default, be restricted to localhost, but a guiding comment or footnote should probably be added. One question is what to do about httpds that don't support access controls. Action: I've submitted a new proposal that addresses only the httpd issue that refers to this one. Bug #27137: Clarification of non-free: packages encouraging donations with claims about non-donation Summary: Update policy to reflect change in definition of contrib Discussion: None Action: This has been incorporated into policy. I'm closing it. Bug #27205: Daemons should run as root only if really needed Summary: See title. Consensus was that this should part of the (as yet unwritten) Debian Coding Guidelines rather than policy. Discussion: None Action: No change in status. It's being left open as a reminder. Bug #30036: Including sub-policies (emacs, menu etc) in policy Summary: Proposed incorporating sub-policies into policy document. Nobody seemed to like this much; a counter-proposal of including the sub-policy docs in the debian-policy .deb gained more support. Lots of concern about mixing of technical details (e.g. how to write a menu-method) with policy (e.g. what is the menu hierarchy). Discussion: This seems to have come to consensus and agreement, as the policy .deb currently contains mime-policy, menu-policy, and perl-policy. No emacs-policy, but I'd guess that audience is small enough there's no problem there. Presumably sub-policy writers will submit their doc when it seems appropriate. Action: close. Bug #33826: Policy should discuss '.sh' suffixes on /etc/init.d files Summary: Policy didn't say anything special about '.sh' scripts. After a few disconnected replies (it seems that some, but not all, messages from another discussion were being forwarded to this bug) it trailed off. Julian Gilbey later asked for a proposed improvement to policy. There were no replies. Discussion: The current version of Policy includes the sentence Also, if the script name ends .sh, the script will be sourced in runlevel S rather that being run in a forked subprocess, but will be explicitly run by sh in all other runlevels which would seem to resolve this bug report. My reading of bug discussion leads me to believe there may another issue: assumptions about sh == bash for those scripts (this wasn't specifically discussed in the proposal, because at the time we didn't explicitly support non-bash /bin/sh, IIRC). Action: I'm going to close this one, but it might be a good idea to address the sh vs. bash issue for '.sh' scripts in /etc/rcS.d. Bug #36151: etc/init.d scripts should specify an explicit PATH Summary: init.d scripts shouldn't depend on having PATH set in a useful manner -- they should explicitly set the PATH. Not much discussion in the bug logs, and most of the flame^H^H^H^H^Hdiscussion took place on debian-devel. Result inconclusive. Last few notes in BTS are that it should be part of the coding guidelines, not policy Discussion: No additional comments Action: Retitle as GUIDELINE for future reminder. Bug #41113: Naming Conventions for modules Summary: Policy should consistent naming conventions for language extension modules (perl, python and java were the examples under discussion). Lots of suggestions, preferences and history, no agreement or concrete proposal. Discussion: Nothing added in over a year. Action: close. Bug #41902: Test suite proposal
Bug#100631: [PROPOSAL] Restrict http access to /usr/share/doc
Package: debian-policy Version: 3.5.5.0 Severity: wishlist In going over some ancient policy proposals, I came across #23661, which proposed eliminating default http access to /usr/share/doc. The conversation wandered off into the usual we shouldn't have services remotely accessible by default discussion, but I'd like to make the following specific proposal (in section 12.5, bullet item 2:) --- policy.sgml.origTue Jun 12 11:27:48 2001 +++ policy.sgml Tue Jun 12 11:34:47 2001 @@ -6494,6 +6494,13 @@ http://localhost/doc/varpackage/var/varfilename/var /example /p + p +The web server should restrict access to the document +tree so that only clients on the same host can read +the documents. If the web server does not support such +access controls, then it should not provide access at +all, or ask about providing access during installation. + /p /item itempWeb Document Root/p I would not object to an ammendment that removed not provide access at all, or from the second sentence. I would object to changing the shoulds to musts, as the present condition has long history, and I don't see this as a critical change. Note that in the discussion of 23661 (http://bugs.debian.org/23661) it was concluded that though to some extent this is security through obscurity, handing a cracker your complete list of installed software was probably not a good idea. I'm asking for seconds. Steve Greenland -- [EMAIL PROTECTED]
Bug#98291: being truthful about the FHS and us
On 09-Jun-01, 11:53 (CDT), Chris Waters [EMAIL PROTECTED] wrote: --- debian-policy.sgml~ Mon May 21 10:45:51 2001 +++ debian-policy.sgmlThu Jun 7 11:59:58 2001 @@ -3983,8 +3983,9 @@ p The location of all installed files and directories must - comply with the Linux File system Hierarchy Standard - (FHS). The latest version of this document can be found + 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 alongside this manual or on url id=http://www.pathname.com/fhs/;. Specific questions about following the standard may be Seconded. It would be nice if there were a footnote to the first sentence listing the D-P sections that conflicted... Steve -- Steve Greenland [EMAIL PROTECTED] pgpr7wSSHnhHL.pgp Description: PGP signature
Re: [PROPOSAL]: encourage use of utf-8 in documentation and clarify encoding issues
On 07-Jun-01, 09:58 (CDT), Radovan Garabik [EMAIL PROTECTED] wrote: + p + Original upstream documentation, if in encoding other than UTF-8 + or the well-established encoding for the particular language, + should be converted either to UTF-8 or to the well-established + encoding. Choice between UTF-8 and other encoding is left to the + maintainer discretion, however, one package should have all the + documentation in one consistent encoding for one language. One bug: the maintainer discretion should be the maintainer's discretion. One suggestion: I think that last phrase might be better expressed as ...however, the documentation for any single package should use only one encoding. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#99714: dh_installexamples: install examples in /usr/share/$package/examples/ (with symlink from /usr/share/doc/$package/examples)
On 02-Jun-01, 17:35 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: On Sat, Jun 02, 2001 at 01:02:38PM -0400, Joey Hess wrote: That is not the intent of policy (I should know; I drafted that modification). The intent is that packages may, rarely, have architecture dependant example files. Such files cannot go in /usr/share, so policy now says put them in /usr/lib, with a symlink to the other location. Not quite ;-) The intent was that *template* files which are used by maintainer scripts to initialise configuration files cannot live in /usr/share/doc. Configuration templates != examples. The former are covered by 11.7.3 (penultimate paragraph) , the latter by 13.7. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Bug#99324: Default charset should be UTF-8
On 30-May-01, 22:25 (CDT), Cesar Eduardo Barros [EMAIL PROTECTED] wrote: On Thu, May 31, 2001 at 01:11:58PM +1000, Anthony Towns wrote: On Wed, May 30, 2001 at 11:11:20PM -0300, Cesar Eduardo Barros wrote: I think Debian should start to move into using UTF-8 by default everywhere. What, exactly, does this involve? - Making sure everything works with UTF-8 charset Does this mean, for example, that cron and crontab would have to be recoded to support wide or multibyte characters? If so, I object to making this a requirement. That's an unreasonable burden to put on a maintainer, and cron is basically unmaintained upstream. (Hell, cron isn't even ISO C!). I suspect there are several core packages that in more-or-less the same boat: widely used legacy packages that haven't changed much in several years, and are so full of assumptions about the text being single-byte that they'd be easier to recode from scratch. I also wonder about the performance impact, and the size impact (although I understand that UTF-8 uses single byte for ascii equivalent, so that shouldn't be much, right?) Now, I agree that encouraging such behaviour might be a good idea (I don't know enough about various encoding to argue one over the other...) Steve -- Steve Greenland [EMAIL PROTECTED]
Bug#99324: Default charset should be UTF-8
Raul, thanks for clarifications. One last detail:
On 01-Jun-01, 15:39 (CDT), Raul Miller [EMAIL PROTECTED] wrote:
For programs with no relevant text manipulation facilities (cron and
crontab), it's sufficient that UTF-8 is not mutilated. [UTF-8 is
designed, remember, to be represented in terms of 8 bit characters.]
The one possible gotcha (I think) is the command string. Suppose the
command is
* * * * * echo some string with UTF-8 encoded characters
(By which I mean a string containing characters outside the ASCII
range). At present cron parses the command simply by reading everything
up to the end of the line ('\n'), char by char (in the C type sense of
'char'). Is there a guarantee that byte value representing '\n' won't
show up in the sequence? Solving this particular problem wouldn't be too
hard in cron, I think, but again, there's a lot of programs that do this
kind of parsing.
Steve
--
Steve Greenland [EMAIL PROTECTED]
Re: Is it allowed to remove old changelog entries?
On 15-May-01, 13:35 (CDT), Santiago Vila [EMAIL PROTECTED] wrote: Who cares about changelogs if there is no requirement that they tell the truth? Because *most* developers will have correct (and possibly even useful) changelogs most of the time. If a few don't, then people will complain, and most of those will fix them. Yes, there will be a very few stubborn idiots left. Deal with it. Life is like that sometimes. Sheesh. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Bug#97072: PROPOSED 2001/05/11] correct policy's comments on standards-version
On 10-May-01, 20:11 (CDT), Anthony Towns aj@azure.humbug.org.au wrote: --- policy.sgml Sun Apr 29 05:10:09 2001 +++ policy.sgml.std Fri May 11 11:10:09 2001 @@ -1186,9 +1186,9 @@ p In the source package's ttStandards-Version/tt control - field, you must specify the most recent version number of - this policy document with which your package complies. - The current version number is version;. + field, you should specify the most recent version number of + this policy document with which your package complied when it + was last updated. The current version number is version;. /p p I second this proposal. -- Steve Greenland [EMAIL PROTECTED] pgp7401VEp8RX.pgp Description: PGP signature
Re: Tasks policy
On 08-May-01, 08:55 (CDT), Sam Hartman [EMAIL PROTECTED] wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Remember: the point of tasks is to make the initial Anthony install simpler, so that people can get started on Debian Anthony without having to wade through dselect. Yes, that was the original point of tasks. However, tasks are also used today by people who want to get a set of software installed after the initial install. If the set of software is a task, then they can run tasksel. If the set of software is just a logical grouping of related packages (emacs, say, or the roxen stuff) then a simple meta package can do the job. Perhaps part of the tasks policy proposal should be to specify an alternative mechanism/naming standard for such groupings (and explain why they are not tasks. Something like appending -group (e.g. emacs-group, roxen-group), so that one can do apt-cache search '-group' to find all those meta packages. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Finishing the FHS transition
On 06-May-01, 14:27 (CDT), Adrian Bunk [EMAIL PROTECTED] wrote: Policy says: -- snip -- In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. -- snip -- Uhh, when did that become a must? In 3.5.2 the first paragraph says You should specify the most recent version of the packaging standards with which your package complies in the source package's `Standards-Version' field. Even in 3.5.4, towards the end of that section it says You should regularly, and especially if your package has become out of date, check for the newest Policy Manual available and update your package, if necessary. When your package complies with the new standards you should update the Standards-Version source package field and release it. It says nothing about uploading just to notify that you are still compliant. Hmmm, I don't remember a proposal to change this; I suspect the must slipped in during the recent rewrites, and as Chris Waters pointed out, it is certainly inconsistent with the intent of the field according to recent discussion. you must specify the most recent version number of this policy document with which your package complies: You must upgrade this field when your package complies with a more recent policy - and when your package does already comply with a more recent policy nothing more than an upload with an updated Standards-Version field is needed. Nonsense. I'm not going to upload new versions of packages simply to change that field. Lot's of policy updates have zero effect on most packages, and I doubt many of our users want to spend the time and money downloading and installing a new version of a package to confirm that. I would strongly object if (for example) Branden suddenly started uploading new versions of the X packages every time a new version of policy was released. I'll wait a few days for one of the policy editors to say Oops, that was an accident; if that's not the case, I need to propose an ammendent that clarifies reality, so that Adrian doesn't get mislead again :-). Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#94827: tktable; Build-Depends: debhelper
On 30-Apr-01, 14:33 (CDT), Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote: You could probably do without the latter two, but IIRC the deb format is internal to dpkg and dpkg-deb is the only supported interface for creating debs. Not true: .deb files are ar(1) archives containing two tar.gz members. See deb(5). (I suspect that support for signed debs implies more members, but not a change to the basic format.) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#94827: tktable; Build-Depends: debhelper
On 01-May-01, 12:19 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: On Tue, May 01, 2001 at 11:45:42AM -0500, Steve Greenland wrote: On 30-Apr-01, 14:33 (CDT), Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote: You could probably do without the latter two, but IIRC the deb format is internal to dpkg and dpkg-deb is the only supported interface for creating debs. Not true: .deb files are ar(1) archives containing two tar.gz members. See deb(5). (I suspect that support for signed debs implies more members, but not a change to the basic format.) AFAIK, ar can't build .debs, even though they use an ar format. There's a slight difference in the components. While admitting that proof by example is not proof, I just used ar to extract the components from an existing .deb (it turns out there is an addition file named debian-binary which is a text file that apparently contains the .deb format version # (currently 2.0\n)), and used ar to create a new .deb with the same three components. The only requirement seems to be that they are listed in the right order: $ ar r ee_1.4.2-3.1_i386.deb debian-binary control.tar.gz data.tar.gz and then used dpkg-deb to list/extract it, and dpkg to install it. Worked just fine. It may be that the (undocumented) debian-binary file is the slight difference you were thinking of. Hopefully, this will not lead to a removal of dpkg-dev from the build-essential list. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#94827: tktable; Build-Depends: debhelper
On 24-Apr-01, 05:25 (CDT), Herbert Xu [EMAIL PROTECTED] wrote: Steve Greenland [EMAIL PROTECTED] wrote: No, I'm suggesting that build-depends could simply have an unversioned depends on debhelper. The buildds would then always[1] have the latest version of debhelper[2]. No effort required of the build-depends maint. But build-time dependencies aren't just for buildd's. Humans need them too. I wouldn't like to have to compile a package and fail near the very end just because it hasn't declared a proper versioned build-depends on debhelper. Sorry, I screwed up in a confusing way throughout: s/build-depends/build-essential/. If you're building packages, you should have the latest versions of the packages listed in build-essential. If a specific package really has a maximum version of debhelper, it could list Build-Depends: debhelper ( x.y) but most packages wouldn't need that, just like most packages don't have a versioned dependency on the C++ compiler. The counter argument is that for people building unstable packages on a stable box with the stable build-essential, latest might not be nearly enough in the case of debhelper. (Of course, the C++ compiler is can move in big jumps too.) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#94827: tktable; Build-Depends: debhelper
On 23-Apr-01, 04:02 (CDT), Lars Steinke [EMAIL PROTECTED] wrote: On Sun, Apr 22, 2001 at 02:24:42AM -0700, Daniel Schepler wrote: Package: tktable Version: 2.6-2 Severity: normal The source package needs debhelper to build. I'd have expected that is a standard build dependency, guess we might have to issue a policy request that the commonly accepted debian package tools are pronounced as such in http://www.debian.org/doc/packaging-manuals/build-essential... Ain't gonna happen. It's been discussed before. The problem is that most debhelper Build-Depends actually need to be versioned[1], which won't work with build-essential. Regards, Steve [1] I personally am not convinced this is the case (simply expecting that the build-essentials install was kept up-to-date would be sufficient), but enough people disagree with me (include the debhelper maintainer, IIRC) that the discussion is not worth pursuing again. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#94827: tktable; Build-Depends: debhelper
On 23-Apr-01, 12:08 (CDT), Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: problem is when following unstable, one sometimes has debhelper depends change fairly often. No sense forcing the build-depends maint to keep up with joeyh's No, I'm suggesting that build-depends could simply have an unversioned depends on debhelper. The buildds would then always[1] have the latest version of debhelper[2]. No effort required of the build-depends maint. *Nobody* can keep up with joeyh. :-) Steve [1] Assuming that the buildds do an update/upgrade on a fairly frequent basis. [2] So far, incompatible changes to debhelper have required the packages using them to specifically request such functionality; debhelper has been a paragon of upward compatibility. I'm sure joeyh and others can point out specific exceptions, but I can't remember an upgrade to debhelper causing problems[3]. [3] Modulo actual bugs in debhelper, of course. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: debian-policy_3.5.3.0_i386.changes INSTALLED
On 18-Apr-01, 07:10 (CDT), Debian Installer [EMAIL PROTECTED] wrote: * Also now Conflicts and Replaces packaging-manual For the record, this is annoying, as I can't[1] upgrade debian-policy without removing the packaging manual, which still contains information that is not available elsewhere. As a side note, did anyone else notice that dpkg-dev 1.8.3.1 containes a completely empty /usr/share/doc/dpkg-dev? Steve [1] Well, obviously I can tar it up and move it elsewhere...still annoying. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Must and should again
On 15-Apr-01, 20:16 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: I guess there are two conflicting desires here: (1) The Acting Release Manager's desire to have it clear what constitutes an RC bug. (2) Developers' desires to know what must be done in all cases and what ought to be done (but there may be exceptions), and what is currently a desirable thing but is likely to one day become an RC requirement. This is indicating to me that Anthony's view is correct for his needs, and Sam and my (and all of the other people who've raised the same issue in recent months) is correct for other people's needs. As a maintainer, I don't have much problem with this, actually. I pretty much treat MUST and SHOULD the RFC way, and don't sweat the subtle difference; it makes (mostly) sense to me that AJ (or whoever) treats them as RC and non-RC level bugs. I suspect that many of us do the same, because most of the MUSTs and SHOULDs make *sense*. I also have no problem in the idea that a maintainer can violate a MUST if that makes sense for his/her particular case (e.g. the recent case of libdvd (or whatever it was) that only made sense as a static lib, even though policy seems to require a shared lib), but the fact that it is a MUST probably means the maintainer will discuss it before violating, to see if there's a better way. And therefore, it would seem that trying to simultaneously use policy as GUIDELINES and as directives of what is RC is somewhat misguided: a good Debian package will fulfill many more requirements than are considered RC. Policy is about relationships between packages, and to a great extent consists of there are lots of ways to do this: this is the way Debian chose. It's a not a complete specification. We've deliberately said that the maintainer is pretty much ghod w.r.t. his/her packages, except where it steps on other maintainers. The vast majority of us seem to be able to deal with that and cooperate in a responsible manner, improving our packages as best we can. Policy should be a minimum, not a maximum. More to the point, we can have violate a MUST == RC Bug (modulo deliberate maintainer choice with good reason) but there is nothing in that says converse is true: there are lots of RC bugs that have nothing to do with policy. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Must and should again
On 11-Apr-01, 18:05 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: [redef of MUST/SHOULD/MAY to RFC definitions; make def of RC bugs orthogonal] Does any of this sound reasonable? Anthony, what do you think of it? I know you've always gone by the must = RC route, but there are lots of people getting really confused by this whole thing, and I think that the RFC route is the far better known. I, for one, like Julian's proposal. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Bug#90511: proposal] disallow multi-distribution uploads
On 30-Mar-01, 17:47 (CST), Brian Russo [EMAIL PROTECTED] wrote: On Wed, Mar 21, 2001 at 12:45:31PM -0500, Ben Collins wrote: + One example of this is if the current version of the + emstable/em and emunstable/em package is 1.2-1, then + a new upload can have 1.2-1.90 for emstable/em and 1.2-2 for + emunstable/em. Each should be compiled on that personally I prefer the foo-1.2-1.potato.1 notation Likewise. Picking arbitrary numbers strikes me as unwise, particularly .90 because it looks like the common beta release convention, not something we want to look like we're doing with the stable release. i always thought incremental debian revisions were for NMU's? I use them on post release revisions, just because it seemed the obvious thing to do. If someone really cares whether or not it was an NMU, the can always look at the changelog. Another possiblity is simply 1.2-1a, 1.2-1b, etc. One possible problem with the 1.2-1.potato.1 convention is what is the proper syntax for an NMU of a stable package? 1.2-1.potato.0.1? It gets silly pretty fast. The whole point of the NMU -x.y convention (as I recall) was simply to make sure that the NMU'r and the developer didn't accidentally re-use the same revision number. Steve -- Steve Greenland [EMAIL PROTECTED]
Bug#91252: PROPOSED] enhanced x-terminal-emulator policy, second try
On 30-Mar-01, 17:50 (CST), Brian Russo [EMAIL PROTECTED] wrote: are there testing utilities available such that one could check that something is in fact 'vt100 compatible' ? export TERM=vt100 vi followed by a little browsing and editing would problably be a good enough test for this purpose. (Note that hardly any of the vt100 compatible terminal emulators are actually capable of doing a true VT100 terminal, there's lots of obscure (and rarely used) features, particularly weird keys.) Steve -- Steve Greenland [EMAIL PROTECTED]
Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
On 27-Mar-01, 23:57 (CST), Anthony Towns aj@azure.humbug.org.au wrote: On Mon, Mar 26, 2001 at 09:35:36AM -0600, Steve Greenland wrote: Encouraging I could agree with, particularly when the check could be automated against the Packages file. But even an automated check against the maintainer scripts is not feasible for most people, and a lot of checks are not possible to automate. A lot of checks are possible to automate: just have a look at lintian some time. Lintian has access to the entire package contents. I only have access to the Packages file(s) and the contents of the packages that I've installed locally. (Which would, admittedly, let me check pretty much everything in standard and higher.) Hmmm, is there anywhere generally available to Debian developers that has all the packages unpacked? So that one could grep all the maintainer scripts or init.d scripts, for example. I suspect I took your original suggestion as a proposed requirement, which I think is unreasonable. As it would be nice if people did this, I have no objection, of course. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Bug#91261: PROPOSED] modernized rewording of X/Motif policy
On 25-Mar-01, 02:45 (CST), Branden Robinson [EMAIL PROTECTED] wrote: * Makes this policy cognizant of OpenMotif, which is now packaged for Debian. Since OpenMotif is non-free, there is no actual policy change if one treats OpenMotif the same as OSF/Motif. This proposal makes that explicit. [and] + footnote + OSF/Motif and OpenMotif are collectively referred to as + Motif in this policy document. + /footnote [and] +but do so when compiled + against Motif, then two versions of the package should be + created; one linked statically against Motif and with + tt-smotif/tt appended to the package name, and one linked + dynamically against Motif and with tt-dmotif/tt appended to + the package name. If OpenMotif is in the distribution, why do packages need to provide a statically linked version? Why can't they go in contrib (DFSG) or non-free (otherwise) with a dependency on OpenMotif, just like other non-free library using software? Steve -- Steve Greenland [EMAIL PROTECTED]
Bug#91261: PROPOSED] modernized rewording of X/Motif policy
On 27-Mar-01, 12:09 (CST), Branden Robinson [EMAIL PROTECTED] wrote: On Tue, Mar 27, 2001 at 10:56:31AM -0600, Steve Greenland wrote: If OpenMotif is in the distribution, why do packages need to provide a statically linked version? Why can't they go in contrib (DFSG) or non-free (otherwise) with a dependency on OpenMotif, just like other non-free library using software? Because I'm not sure there is 100% compatibility between the version of OSF/Motif that a package may be coded against, and between the version of OpenMotif that we ship. In other words, I'm not willing yet to yank the rug out from under all Motif-linked packages and tell them make sure it works with OpenMotif instead. I wasn't clear enough: I meant that packages built against the OpenMotif need not supply the static version. Packages linked against OSF/Motif would still need both static and dynamic. I was envisioning up to 4 different versions of each package: OSF-dynamic, OSF-static, Open-dynamic, and Open-static, and didn't see much need for the last of these. If it is the case that if the libraries are supposed to be binary compatible (and some after browsing around openmotif.org, I'm still not sure), and we'd still have only two: static (presumably either OSF or Open) and a dynamic (that should work with either) then I completely agree with your wording. Steve -- Steve Greenland [EMAIL PROTECTED]
Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
On 25-Mar-01, 04:26 (CST), Anthony Towns aj@azure.humbug.org.au wrote: If you create a must directive, then you've just created a reason to have a number of extra RC bugs. Indeed, that's the only point of making it a must instead of a should. The point of making a must requirement is that the consequences of not following that requirment are sufficiently serious to justify removing a package that does not follow that requirement. The number of packages affected is largely irrelevant. If I propose that packages must not call 'rm -rf /' in their postinst script, we could all agree that it was a completely reasonable requirement no matter how many packages were affected. If you're not going to bother filing the RC bugs, there's no reason not to leave it as a should. If you are going to file the RC bugs, then someone's got to figure out which packages it applies to at some point anyway. There's a huge difference between you have to find all the affected packages and someone (probably many people) will have to find the affected packages. Are you also going to require that each person who suggests a modification to a proposal adjust the list appropriately? And who gets to keep up with checking the new packages every day? Because people don't seem to understand the point of the must/should dichotomy. The must/should dichotomy is (or at least should be) based on the real consequences of not following a recommendation. The bug system severities are just there to make it easier to track. Encouraging people to list the packages which'll have RC bugs filed against them due to a proposal they're making doesn't seem particularly drastic. Encouraging I could agree with, particularly when the check could be automated against the Packages file. But even an automated check against the maintainer scripts is not feasible for most people, and a lot of checks are not possible to automate. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Bug#90511: new-proposal] (was disallow multi-distribution uploads)
On 22-Mar-01, 10:28 (CST), Ben Collins [EMAIL PROTECTED] wrote: I'm pondering a new angle to this. Perhaps we don't even need to mess with dinstall. What would really suffice is a check in the testing scripts that disallows anything moving from unstable to testing if it depends on something marked obsolete. I still think there is a problem with allowing packages built on stable into unstable. As others have pointed out, there is the issue of policy changes, in particular file locations and the scripts generated by helper packages. Of course, the assumption is that a package being uploaded to both dists hasn't changed in either dist anyway, so policy compliance won't *decrease*. Steve -- Steve Greenland [EMAIL PROTECTED]
Bug#90511: proposal] disallow multi-distribution uploads
On 21-Mar-01, 11:45 (CST), Ben Collins [EMAIL PROTECTED] wrote: @@ -1434,15 +1434,23 @@ /p /item - tagemfrozen/em/tag + tagemtesting/em/tag ^^^ But later wrote: + is a time constraint before migration. Note, you cannot + upload directly to emtesting/em as you can with + emstable/em and emunstable/em. This distribution + is the base for the next planned release. Did you mean experimental in the first part? Steve -- Steve Greenland [EMAIL PROTECTED]
Bug#89473: PROPOSAL] dpkg-statoverride and Conflicts: suidmanager ( 0.50)
On 13-Mar-01, 13:05 (CST), Ben Gertzfield [EMAIL PROTECTED] wrote:
Wichert == Wichert Akkerman [EMAIL PROTECTED] writes:
Wichert Policy should set guidelines for making packages [...]
Wichert The less details, the better.
Um. Policy *IS* the guide for making packages now. There's no
Packaging Manual any more, and so these kinds of details must be
included in policy. There's no other place to put them!
I don't think that's the case: parts of the packaging manual were moved
to policy (because they were policy type stuff), and the rest needs to
be re-packaged as the packaging guide.
A lot of stuff, like how the {pre,post}{inst,rm} scripts work, needs to
be documented but should absolutely positively not be in policy.
I'd rather be able to read one document and learn how all the dpkg
tools work.
Agreed, but that document is *not* the policy document.
Steve
--
Steve Greenland [EMAIL PROTECTED]
Re: [PROPOSAL] Allowing crypto in the main archive
On 29-Jan-01, 20:07 (CST), Anthony Towns aj@azure.humbug.org.au wrote: On Mon, Jan 29, 2001 at 07:34:57PM -0600, Manoj Srivastava wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Are you going to go through the distribution and maintain a Anthony list of which packages all these tags apply to, and which Anthony they don't? Heh. Sure. I'll do it once. And your proposal has no way of ensuring the tags are either accurate, or are maintained. You'll do it once, or you'll actually maintain them? I don't see the point of keeping around non-* tags if no one is going to make any effort towards keeping them up to date. Why do you keep agreeing with Manoj in a way that seems to imply you disagree? :-) This is Manoj's point (as I understand it, anyway (and agree with)): The non- tags won't be maintained in a reasonable way, and there is no way for Debian (as a whole) to responsibly encourage people to rely on them, so they are of negative value (because people *will* rely on them). Adding them to policy will just mislead our users (in whatever form: mirrors, cd producers, etc.) into thinking we've actually validated against a given country's laws. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Bug#76868: invoke-rc.d FINAL PROPOSAL
On 23-Nov-00, 05:13 (CST), Henrique M Holschuh [EMAIL PROTECTED] wrote: The policy proposal itself is attached to this email, I am looking for seconds, now. The proposal has been seconded once so far, by Anthony Towns [EMAIL PROTECTED]. I second this proposal, presuming the constrains == constraints typo fix. Steve -- Steve Greenland [EMAIL PROTECTED] pgpEOWBLJkWjW.pgp Description: PGP signature
Re: 60979@bugs.debian.org, 20373@bugs.debian.org
On 17-Jan-01, 23:28 (CST), Manoj Srivastava [EMAIL PROTECTED] wrote: Hi, Does someone have an interest in pushing these proposals through? What is needed is to have the skeleton code written by Julian fleshed out, add support for file-rc, and then submitted as a patch for the sysvinit package. Aren't these both superceded by Henrique's invoke-rc.d (#76868)? (Hmmm, don't see anything from Henrique since late November...) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: changing priorities
In general, I like the names and descriptions better than what we have currently. However, I see a problem with the criterion for getting something into common. It is likely that some maintainers will take it as an insult to have their package demoted to common, and to I'd think a restriction something like ``all `common' packages must be included in at least one task'', which means they only get to be common if they can convince one of the task maintainers to include their package. I might be tempted to respond with: Package: task-steveg-favorites Depends: ddclient, jargon, cern-httpd Now of course that's rather silly, not to mention completely in-approrpriate, but given the current growth in task packages and the resistance to Joey's clean-up proposal, I can see it happening. We might well end up with the ftp maintainers stuck having to apply overrides, which will make good sense to most of us, but lead to cries of censorship and cabal from those affected. No, I don't have a better solution right now, just picking holes. steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Bug#79538: FDL is missing from common-licenses
On 14-Dec-00, 17:20 (CST), Chris Waters [EMAIL PROTECTED] wrote: On Thu, Dec 14, 2000 at 01:09:33PM -0500, Susan G. Kleinmann wrote: But I think we're all hoping that the FDL actually becomes common, and putting it into the common-licenses directory is one step toward making that happen. I would describe it more as putting the cart before the horse. At the moment, common-licenses is just that. Licenses that _are_ common. Perhaps we can put FDL in: /usr/share/licences-we-hope-become-common-someday Normally I'd agree with this (policy should follow practice), except for one possibility. It might be that some software/document writers *look* in /usr/share/common-licenses and pick the one they like best[1]. So yes, it may be a license we hope becomes common, but we could perhaps help it along. And I don't see any real negative by having it there. Steve [1] Of course, reading debian-legal shows that most writers prefer to make up their own crappy licenses that don't do what they think they do and usually make things undistributable. Sigh. -- Steve Greenland [EMAIL PROTECTED]
Re: cleaning up our task packages
On 08-Dec-00, 02:29 (CST), Britton [EMAIL PROTECTED] wrote: Also, why should the user ever see a task like devel-common, shouldn't this be essentially depended on by all the dev tasks? And Debug should be pulled in for any languages for which it includes debugging tools. No, that's backwards, there shouldn't *be* a task-debug; task-devel-lang should include the appropriate debugger. If there's more than one, pick the one that crashes the least, or has the best documentation or (better yet) tutorial. Remember, we're trying to make things easy for people who don't yet have the experience to make a choice. There is *nothing* about task packages that prevents them from exploring other options. We can, for example, pick gdb and ddd (no idea if that's the best choice), and if the user later finds out about insight or code-medic, they can install them. In fact, a quality task-* package would include in _its_ documentation a (brief) discussion of why each package was chosen, and a list of alternatives. steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Use $DEB_BUILD_DIR rather than parent directory?
On 20-Nov-00, 09:37 (CST), Eric Gillespie, Jr. [EMAIL PROTECTED] wrote: I recently filed this wishlist bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77153repeatmerged=yes) against dpkg-dev, and Wichert told me to take it up with policy, so here i am. I think it would be nice if the package-building tools would place files in $DEB_BUILD_DIR if it is set. If it isn't, they will continue their current behavior of dropping them in the parent directory. I, for one, would like this feature. I'm vastly confused about why it would be a policy issue, though. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Use $DEB_BUILD_DIR rather than parent directory?
On 20-Nov-00, 11:32 (CST), Wichert Akkerman [EMAIL PROTECTED] wrote:
Previously Steve Greenland wrote:
I, for one, would like this feature. I'm vastly confused about why it
would be a policy issue, though.
because it means all debian/rules files need to be changed to replace
dpkg --build debian/tmp ..
with
dpkg --build debian/tmp $(DEB_BUILD_DIR)
Or just modify dpkg (or actually dpkg-deb, I guess) could be modified
to look for the environment variable DEB_BUILD_DIR and use it if it
was defined, requiring no changes at all to the debian/rules files. I
assumed that was the whole point of the proposal. Since dpkg-deb already
supports an alternative target directory, I can't believe that this is
all that difficult. In fact, here's a (briefly) tested patch:
--- dpkg-1.7.1.1/dpkg-deb/build.c Tue Aug 22 16:21:59 2000
+++ dpkg-1.7.1.2/dpkg-deb/build.c Mon Nov 20 12:30:29 2000
@@ -175,13 +175,13 @@
subdir= 0;
if ((debar= *argv++) !=0) {
if (*argv) badusage(_(--build takes at most two arguments));
-if (debar) {
- if (stat(debar,debarstab)) {
-if (errno != ENOENT)
- ohshite(_(unable to check for existence of archive
`%.250s'),debar);
- } else if (S_ISDIR(debarstab.st_mode)) {
-subdir= 1;
- }
+ }
+ if (debar || ((debar = getenv(DEB_BUILD_DIR)) != NULL)) {
+if (stat(debar,debarstab)) {
+ if (errno != ENOENT)
+ohshite(_(unable to check for existence of archive `%.250s'),debar);
+} else if (S_ISDIR(debarstab.st_mode)) {
+ subdir= 1;
}
} else {
m= m_malloc(strlen(directory) + sizeof(DEBEXT));
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
pgp1unJoKrDqD.pgp
Description: PGP signature
Bug#76868: invoke-rc.d proposal)
On 16-Nov-00, 20:30 (CST), Anthony Towns aj@azure.humbug.org.au wrote: For example, /etc/init.d/chrony has an e) instead of a *) as its error case, which means it'll quietly exit successfully. /etc/init.d/nviboot does likewise, but through omission rather than accident. re: nviboot: you're right, I'll fix that. /etc/init.d/cron and /etc/init.d/setserial treat unknown arguments the same as start. Error output goes variously to stdout and stderr. Re: cron: Huh? On what system? speedy:~$ /etc/init.d/cron sadf Usage: /etc/init.d/cron start|stop (yeah, the usage message is out of date, and needs to be fixed, but it's certainly not the same as start.) Steve -- Steve Greenland [EMAIL PROTECTED]
Re: [RFC] Package build time config for installation directories.
On 06-Nov-00, 09:10 (CST), Ben Collins [EMAIL PROTECTED] wrote: On Mon, Nov 06, 2000 at 03:26:56PM +0100, Nils Lohner wrote: So I guess the system needs to support functionality that I can use the .orig.tgz files (no debianization) because then I can just apt-get source and build and have it work, meaning I can automize a dir with non- standard stuff on solaris. This would also make the system completely non-debian dependent (i.e. people can use it on hp-ux for maintaining a GNU tools tree in /opt by downloading, compiling and installing sources for example) and allow for a lot of flexibility. But if you have apt available, why not use the debianization? :) A much better question is that if he wants to use the .orig.tar.gz files, and they can be built with a single line configure command, why should I spend time and effort to support non-Debian systems, especially non-free ones? Ben, I don't really see the point of all of us spending time to support non-Debian systems. I don't have much interest in seeing dpkg take over the universe. The point of having standards such as the FHS is to avoid this kind of kludgery. And yes, I maintain packages where there would be a lot more effort to follow this proposal than just sourcing the file and changing a few configure commands. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: [RFC] Package build time config for installation directories.
On 06-Nov-00, 10:22 (CST), Ben Collins [EMAIL PROTECTED] wrote: Ben, I don't really see the point of all of us spending time to support non-Debian systems. I don't have much interest in seeing dpkg take over the universe. The point of having standards such as the FHS is to avoid this kind of kludgery. Please reread my original post. Two of the three cases involve actual Debian ports (either present or future). Ok, I did. 1. Non-FHS ports. This seems to me a contradiction in terms. Marcus has weighed in with but HURD *is* FHS, and I don't see why other ports can't be as well, especially as HURD is the least unix like of the listed OS's. If it can't be made FHS compliant, then perhaps it's not an appropriate target for a Debian port. What's next, and NT port? 2. Overlay systems (e.g. 64bit ports) Ok, this one I see, but it would seem to affect primarily libraries, right? And aren't they going to have to detect architecture and special case stuff besides directory names (e.g. compiler switches, etc.) anyway? So this doesn't help them all that much. 3. Third-party stuff. Don't care. Requiring developers to accept technically competent and reasonable patches to enable this is something I think should be required (e.g. if someone files a bug that correctly solves this issue, you either accept the patch, or leave the bug open at normal severity). Fair enough. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: [RFC] Package build time config for installation directories.
On 06-Nov-00, 13:35 (CST), Ben Collins [EMAIL PROTECTED] wrote: On Mon, Nov 06, 2000 at 10:58:30AM -0600, Steve Greenland wrote: 1. Non-FHS ports. This seems to me a contradiction in terms. Marcus has weighed in with but HURD *is* FHS, and I don't see why other ports can't be as well, especially as HURD is the least unix like of the listed OS's. If it can't be made FHS compliant, then perhaps it's not an appropriate target for a Debian port. What's next, and NT port? Hurd is probably not the best example...so I retract it as one. So what about the others? Why can't they be FHS compliant? If they can't, why are people a) attempting to port Debian to them? b) expecting every other developer to accomodate their weird needs? 3. Third-party stuff. Don't care. Third-party != non-free OS, so I hope that isn't the basis for your opinion. Dpkg and Debian policy is a fairly powerful tool that I would hope extends well beyond just us. If this benefits them, it is a plus, not a ooops, oh well. No, it's not that it's non-free, it's that I do not understand why I and every other developer are being asked to modify our packages and possibly the upstream source in order to support people who are not using Debian systems. I don't see support our packaging system on arbitrary systems anywhere in the project goals. Yes, if someone outside the project benefits from the work we do, that's great. But doing work to benefit those outside the project (and by project, I mean our users as well, of course, not just the developers) rather sticks in my craw. So yes, if this is necessary to support the various 64bit ports, then great (even after your explanation, I'm not sure that it does, but I don't know enough to argue, so I'll let others do it :-)). If not, then pushing the benefits to non-Debian system users doesn't mean a whole lot. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: RFC: initscript policy proposal
On 31-Oct-00, 21:03 (CST), Henrique M Holschuh [EMAIL PROTECTED] wrote: I'd prefer to get this whole invoke-rc.d deal into policy with an optional maybe-restart first to fix the worst mess. After it's in policy, any developer can propose changing maybe-restart to non-optional and we can have the flamewar without endangering the whole initscript fix :-) That sounds like a very reasonable approach, especially given the (presumably) rare situation of I'm running a daemon by hand that usually doesn't run at this runlevel and upgrading it too. Consider my mild objection/concern withdrawn for now. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: RFC: initscript policy proposal
Generally very nice (haven't read the actual scripts yet...). I definitely approve. I've one question/concern/objection, though. In your diff of 3.3.3.2, you have: + By default, `invoke-rc.d' will pass any action requests (start, stop, + reload, restart...) to the /etc/init.d script, filtering out requests + to start a service out of its intended runlevels as defined by + `update-rc.d' and the system administrator. Also, requests to restart a + service out of its intended runlevels are changed to a stop request. The last sentence causes a problem in the following (contrived?) scenario. 1. Daemon foo is not configured to run at current runlevel. 2. I, the sysadmin, have started foo by hand. 3. I do a apt-get upgrade, which includes a new versin of foo. Because of restart converted to stop, foo is stopped. I propose that instead of restarts converted to stops we just go with restarts ignored. I realize that this would cause the new version of foo to be ignored, but that may be less surprising than having foo go away completely, OTOH, if 'maybe-restart' worked even if foo is not configured at the current run-level (it's not clear to me that it does or doesn't, but I only did quick skim of the descriptions), and packages strongly urged to use it in the postinst, that would be a better solution. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Priorities
While I mostly agree with Adam, there's one nit I'd like to pick: On 14-Oct-00, 21:03 (CDT), Adam Di Carlo [EMAIL PROTECTED] wrote: * browsing the web (without having to download plugins all the time, having java support, etc) Well, we do have virtual packages for this. [...and...] The task-* packages are meant for pulling in a lot of pakcages, whereas the virtual packages present alternatives, such as, to the question I want a free SQL server. Virtual packages don't really server this purpose, as there is no way for the user to select them. Virtual packages exist so that other packages can depend on the presence of a specific function w/o depending on a specific package. If you want to provide such a function for the user (show me all the web browsers), implementing keywords would be a better, more useful choice. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Priorities
On 04-Oct-00, 14:27 (CDT), Anthony Towns aj@azure.humbug.org.au wrote: So I wonder if changing it to something more like: 'important': things that will be on *every* system, except *very* specialised ones 'standard': everything that might reasonably appear in an off the shelf install 'optional': everything else that doesn't conflict with anything above 'extra': anything rare, or conflicting with optional or higher packages If we're going to mess with priorities, this would be the time to introduce the new priority between standard and optional: preferred: The Debian preferred implementation of a common service that has multiple implementations (e.g. webservers, SMTP, mp3 players, etc.) (Yes, I know it's opening a hornets nest. But optional is just too dang big, and we could just pick one, admit that it's arbitrary, and go on.) Someone (IanJ?) had a more detailed proposal for this a while ago, I'll see if I can dig it out. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Bug#72980: virtual packages list layout
On 02-Oct-00, 07:14 (CDT), Josip Rodin [EMAIL PROTECTED] wrote:
should also contain these virtual packages from the Miscellaneous section:
pdf-preview Any preprocessor that creates PDF output
pdf-viewer Anything that can display PDF files
postscript-preview Any preprocessor that creates Postscript output
postscript-viewer Anything that can display Postscript files
Of what possible use are the -preview virtual packages? What would
depend on any prepreprocessor that creates {PDF,PS} output?
Steve
--
Steve Greenland [EMAIL PROTECTED]
Re: Priorities
On 09-Oct-00, 13:57 (CDT), Anthony Towns aj@azure.humbug.org.au wrote:
On Mon, Oct 09, 2000 at 12:13:47PM -0500, Steve Greenland wrote:
preferred: The Debian preferred implementation of a common service that
has multiple implementations (e.g. webservers, SMTP, mp3 players, etc.)
Couldn't that just go in standard under the above? (I presume the
preferred mp3 encoder/player would be brough in by a task-annoy-the-riaa
package or similar). What if we have multiple preferred packages that
don't conflict (mp3 players, mail readers, editors, ...)? Is that a problem?
I don't think it really is, personally.
It's not standard because they are things that may not be necessary or
even common.
As far as mutliple preferred packages, my intent is that such a phrase
is an oxymoron; the whole *idea* is help the users select one particular
implementation out of several possibilities. Basically, we'd be saying
If you're not sure which {web-server, whatever} to install, try this
one first.
It's not the same as task packages, because the intent of those (as
I understand it) is to group various packages that work together. I'm
also bothered (a little) by the task-webserver-roxen (why is there no
task-webserver?), in that it doesn't offer much guidance (because it
implies the existence of t-w-apache, t-w-boa, etc.).
Maybe we shouldn't be in the guidance business. But if we're going to
mess with the definitions of the priorities (which I think is a good
thing, if only to clarify *our* thinking), then this is the time to
consider the idea.
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Re: Bug#70269: automatic build fails for potato
On 09-Sep-00, 02:57 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: Chris == Chris Waters [EMAIL PROTECTED] writes: Chris Actually, since policy is already available on-line, it's quite Chris possible that many debian developers *don't* have the policy package Chris installed. Hmm. Don't we all have task-debian-dev installed? I suspect a good many of us don't have *any* task-* packages installed, esp. if our initial install predates the task packages. Once one has a nicely set up system, why would I mess with the task packages? Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#70269: automatic build fails for potato
On 31-Aug-00, 12:43 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: On Thu, Aug 31, 2000 at 08:29:30PM +0300, Antti-Juhani Kaijanaho wrote: Which is just a stupid pain in the ass. I had to track through three different references and finally install the build-depends package to find out what I could leave out of by Build-Depends stanza. It would *much* easier for developers, if less ideologically pure, to just list the damn packages on the Developers Corner part of the website. Could we add this as a footnote to the relevant section in policy or the packaging manual (can't remember which offhand)? Um, the current note in policy manual is not sufficient? (It explicitly mentions the package build-essential.) I guess. Maybe he didn't look in the right place ;-) rant That would be cute if the right place wasn't so fucking hard to find. The policy manual says look in build-essential. The control file for Build-essential says look in policy manual, and includes two different list files, one of which is completely pointless, the other of which has the needed info buried in the middle of a bunch of definitions and syntax. This is all needless run-around. Just put the list on the website, and in the policy manual as a footnote. I *understand* that the list is not the official definition. Feel free to post the official definition, and the say the current list x, y, and z. But stop making people spend 15 minutes hunting for information that should be listed everywhere that that build-depends is mentioned. /rant Why are people determined to make information so hard to find? Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: PLEASE: standard package README file/orientation
On 23-Aug-00, 18:17 (CDT), Daniel Barclay [EMAIL PROTECTED] wrote: From: Steve Greenland [EMAIL PROTECTED] ... Current policy requires that /usr/doc/package exist (possibly as a symlink to /usr/share/doc/package). Then why don't more package implement that policy? Because they're *broken*, as I said before. Instead of arguing here, why don't you report bugs against the broken packages? It is not the maintainer's job to keep a packages upstream documentation up-to-date. Sorry, but that's the way it is. So? I didn't say it was. I didn't say that Debian maintainers should clean up upstream documentation. You said that if the upstream package doesn't have an orientation document, then we should create policy to mandate that the Debian maintainer write such a document. You said that if the upstream documentation was jumbled or out of date, then the maintainer need to fix it, or provide a replacement. If that's not what you wanted them to do, what exactly *did* you want, and how does it help? I just argued that in doc directory, which typically contains a mess of upstream files, there should be a file that is easily recognizable (having a standard name) as the Debian README file. And what content do you want in it? From your previous posts, I understood that you wanted an overview of the package contents (dpkg -L), a list and description of other relevant documents, and perhaps a where to go next. That sounds like (what is properly) upstream documentation to me. If a maintainer chooses to write such a document (and possibly submit it upstream), then that's great. Having such a document mandated is not. If Debian really thinks that is sufficient, then this is hopeless. I don't know what Debian thinks. I only know what I think. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: PLEASE: standard package README file/orientation
On 22-Aug-00, 23:12 (CDT), Daniel Barclay [EMAIL PROTECTED] wrote: Some packages don't have a documentation directory at all. Then they are in violation of the Debian policy. Current policy requires that /usr/doc/package exist (possibly as a symlink to /usr/share/doc/package). Some others do but their files are so scrambled that you can't tell which are current, which are obsolete (because of, e.g., Debian clean-up of how the package works), etc., without reading each file. It is not the maintainer's job to keep a packages upstream documentation up-to-date. Sorry, but that's the way it is. If the maintainer does something to the package obsoletes or otherwise breaks the upstream documentation, then that info *should* be in changelog.Debian.gz, if nowhere else. PLEASE remember what changes, especially for the user installing the software, between building and installing from source tarballs vs. installing distribution packages: [snip description of README, etc.] If that information is provided by the upstream package, then it should be included in the doc directory, under the same name. Policy specifically allows for build and installation instructions to be omitted, but other materials should be included. That they are not is a bug in the package, not in policy. Debian packages don't provide that orientation reliably at all. ls -l /usr/doc/foo dpkg -L foo |grep bin dpkg -L foo |grep man dpkg -L foo |grep info works for *every* package. (Yes, I know it would be more efficient to combine into one dpkg -L command, I left it as an exercise for the reader.) We do have directory /usr/share/doc/package/ (well, for some packages), You're looking in the wrong place -- we haven't completed the transition to /usr/share/doc yet -- the canonical place is /usr/doc. Look, I share some of your frustrations. But the problem is with individual packages not included the upstream materials, or the lack of upstream materials. If a maintainer chooses to augment what's upstream that's great. Writing a policy requirement for such is not. Steve
Re: Bug#62378: Redundant directory and package name
On 22-Aug-00, 23:53 (CDT), Nicol?s Lichtmaier [EMAIL PROTECTED] wrote: What about the /usr/doc/foo symlink -- is foo-doc going to take care of that? What if I later install foo? Who gets to remove the link? I don't know, but this kludge is a secondary thing, and should not be considered when making policy. Any policy will last longer than these symlinks. Uuh, those symlinks *are* in policy. You can't just ignore them. Steve
Bug#69487: the example for using nostrip in DEB_BUILD_OPTIONS is incorrect
On 20-Aug-00, 15:24 (CDT), Ben Collins [EMAIL PROTECTED] wrote: The nostrip check needs to be inside the debug check. Because of you are not compiling with debugging turned on, there's no reason to not strip the binaries. So (note, the blank should go first): ifneq $(findstring debug,$(DEB_BUILD_OPTIONS)) CFLAGS += -g ifeq $(findstring nostrip,$(DEB_BUILD_OPTIONS)) INSTALL += -s endif endif While I agree with the philosophy, this code snippet is wrong, as it will add the -s iff DEB_BUILD_OPTIONS includes debug but not nostrip. Hmm, so is the example in the policy manual...if DEB_BUILD_OPTIONS is unset, INSTALL is 'install', not 'install -s'. Here's a correct version: CFLAGS = -O2 -Wall INSTALL = install ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g endif ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL += -s endif (note the second conditional is 'ifeq', not 'ifneq'.) Steve
Bug#69487: the example for using nostrip in DEB_BUILD_OPTIONS is incorrect
On 23-Aug-00, 16:26 (CDT), Franklin Belew [EMAIL PROTECTED] wrote: On Wed, Aug 23, 2000 at 02:59:39PM -0500, Steve Greenland wrote: While I agree with the philosophy, this code snippet is wrong, as it will add the -s iff DEB_BUILD_OPTIONS includes debug but not nostrip. This makes perfect sense, as when you strip a binary, you kill the symbol table and hence -g is useless But if DEB_BUILD_OPTIONS is not defined, then INSTALL remains install, and the files are not stripped when installed (into debian/tmp), which I don't think is the desired effect. (Note that the result of debian/rules build is still the unstripped binary file(s).) Steve (Please don't cc me on list mail)
Re: Bug#62378: Redundant directory and package name
On 22-Aug-00, 18:27 (CDT), Nicol?s Lichtmaier [EMAIL PROTECTED] wrote: 1. I subtly avoided those by specifying doc- rather than -doc :-) FWIW, I think we ought to come to agreement about the proper behaviour: right now I don't know *where* to look after installing foo-doc. Here the solution is clear to me. A package mutt-doc documenting mutt should put its files under /usr/doc/mutt, i.e. where a user will go to find mutt documentation. That makes sense, except that my usual sequence is this: 1. Look for docs in /usr/doc/foo -- nothing there. 2. apt-get install foo-doc -- success. 3. Since I just installed foo-doc, I tend to look in /usr/doc/foo-doc for the new materials. Silly me. There doesn't seem to be policy on this...maybe there should be. One argument for putting it in .../foo-doc is that if I want the docs without foo, perhaps to see if I want to install it, or if I need/want the docs on a different machine than I need/want the package (think firewalls...) Steve
Re: Bug#62378: Redundant directory and package name
On 22-Aug-00, 21:02 (CDT), Nicol?s Lichtmaier [EMAIL PROTECTED] wrote: Think this: Do the docs document the docs? /usr/share/doc/mutt documents mutt, but /usr/share/doc/mutt-doc... documents... what? mutt-doc? Is a nonsensical place for documentation, I think. It only has some sense from a package management perspective, but that's not ok, package manage should be invisible to the end users, and things shoould fall in the most intuitive place... I M H O. =) I tend to agree with you, but it's not completely cut-n-dry: 1. Consider the I want foo-doc w/o foo: Is it ok for foo-doc to create /usr/share/doc/foo and put stuff in it? What about the /usr/doc/foo symlink -- is foo-doc going to take care of that? What if I later install foo? Who gets to remove the link? 2. What about (first example I found) the tetex situation? There isn't a tetex package, so where does tetex-doc install its stuff? (The answer seems to be under tetex-doc, with a link in each /usr/share/doc/tetex-*/ directory.) At present, it's pretty random. I would like a consistent answer to make its way into policy, but there are lots of different cases, and I don't think a simple foo-doc installs stuff into /usr/share/doc/foo is the best answer. One must also consider that some doc package are actually (at least partially) info files and man pages. Part of the problem is that we've conflated package docs (copyright, changelog.Debian.gz,etc.) with user docs. Steve
Re: Bug#62378: Redundant directory and package name
On 21-Aug-00, 14:10 (CDT), Nicol?s Lichtmaier [EMAIL PROTECTED] wrote: Except that a package named doc-rfc will already have files in /usr/share/doc/doc-rfc (copyright and so forth), and so having others in /usr/share/doc/rfc is a little weird and unexpected. For you. Not for me. And I can't think why it would be for the users. Because after installing a package, they are used to looking in /usr/share/doc/pkgname? I expect that when I install a package named doc-, all if its content is going to be in /usr/share/doc/doc-. The Debian standard, whether spelled out in policy or not, supports such expectation. Steve
Re: Bug#62378: Redundant directory and package name
On 21-Aug-00, 15:56 (CDT), Nicol?s Lichtmaier [EMAIL PROTECTED] wrote: I expect that when I install a package named doc-, all if its content is going to be in /usr/share/doc/doc-. The Debian standard, whether spelled out in policy or not, supports such expectation. That's a half true. Many packages install files in the doc directory of the package being documented. /usr/share/doc/doc-rfc/ should only have a changelog and a README. 1. I subtly avoided those by specifying doc- rather than -doc :-) FWIW, I think we ought to come to agreement about the proper behaviour: right now I don't know *where* to look after installing foo-doc. 2. There is no rfc package for rfc-doc to install with. (Yes, both of the above points are rather facetious...) Besides, it would be nice to have many rfc packages: doc-rfc-mail, doc-rfc-web, all of them puting packages in /usr/share/doc/rfc. And there could be symlinkf pointing to the most recent versions of standards: /usr/share/doc/rfc/HTTP would point to rfc2616.txt. This is a good argument. I think combined with Colin's idea that it be called /usr/share/doc/RFC (embracing and extending the HOWTO example) I could be in favor of it, as it avoids the package namespace. Steve
Bug#27137: REJECTED] Clarification of non-free: packages encouraging donations with claims about non-donation
On 04-Jul-00, 18:05 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: So are people happy with changing the wording of the last two lines to read: otherwise they must go in non-free. FWIW, I'm happy with that. steve greenland
Re: problem with emacs configuration scripts
On 02-Jul-00, 23:38 (CDT), Thomas Bushnell, BSG [EMAIL PROTECTED] wrote: Specifically, because the files are conffiles, they are not removed when the package is removed, and so the files stay around to continue to affect the behavior of emacs. This happened to me with the user-de and user-es packages, which I installed long ago, and long ago removed. But the scripts they install have a bug on current emacs20, and because the scripts are conffiles, they didn't get deleted. That's a bug. It's not a policy violation, but it's still a bug. IMO, we don't need to document every possible bug in policy. We *do* need to make it clear to maintainers that so-and-so doesn't violate policy, so it's not a bug is *not* a valid argument. There are lots of bugs that don't violate policy (I don't think policy says anywhere though shalt not dump core, for example), so this should be obvious, but apparently it's not. And by the way, apt *does* support purge: apt-get --purge remove foo. (Hmm, it doesn't show up in apt-get --help, only in the manpage.) Steve
Re: 'editor' alternative policy?
On 22-Jun-00, 04:09 (CDT), Jordi Mallach [EMAIL PROTECTED] wrote:
What I see in /v/l/d/a/editor is the priorities are random now. In my
system,
/bin/ae 20
/usr/bin/joe 70
/usr/bin/nano 40 (I copied from Pico, IIRC)
/usr/bin/vim 20
And I don't think a priority of 70 conforms to any rationale.
It's not random. It was discussed/decided by all the developer's who
maintained editors at the time the editor alternative was created, with
Dale Scheetz doing most of the work. I finally tracked down the original
mails. Dale: I'm going to assume that re-publishing these is OK, since
even though they weren't originally list mails, they're hardly personal.
First Dale sent out an e-mail with a proposed list of priorities, and a
rationale for them:
Date: Sun, 2 Nov 1997
First, without wishing to start an editor war, I am going to make
the assumption that vi should be the default editor in a standard
installation. As nvi is marked standard, it fits the criterion for
the standard vi and thus the standard editor. It should therefore
have a priority above all other non-vi candidates (with one exception
{elvis-tiny, which I will group with ae, and friends}). The other
vi-clones (vim, and elvis are the only two that come to mind) should
have higher priorities than nvi, so that, when installed, they will
become the default. That is, if you are installing optional software
the easy assumption is that you are doing so because you like it
better than what is already available. This implies that you would
prefer it to be the default editor. If, instead, you are only
providing for a limited number of your user-base (greasing a squeeky
wheel) and don't want it to be the default, there is an easy way to
lock in the sysadmin's preference.
Second, I made the assumption that there were some editors on this
list that would, under normal circumstances, never wish to be used as
the default editor. While emacs is the first thing to spring to mind
;-) in this context. I have assumed that, if all other good default
editors were removed from the system, emacs is not the worst thing to
be left with. (This should appease the emacs purists ;-)
While it is not explicitly stated (even in the code) anywhere what
range of values are permissable, the code for update-alternatives says
that a priority must be an integer. It turns out there are no other
restrictions on the value of priority, which means that both positive
and negative values are permissable up to the value of MAX_INT. While
I don't think we need quite this much range for this project, I will
use the negative numbers.
Then followed his initial list. I'm not including it, because it changed
quite a bit during the ensuing discussion. After a few rounds, here's
the final list (as I have it -- if there have been changes since, I've
lost them..)
Date: Thu, 13 Nov 1997
Here is my proposed priority list:
elvis 120
vim 110
Standardnvi 100
fte 90
jed 80
joe 70
beav60
ee 50
pico40
elvis-tiny 30
Baseae 20
ed 10
emacs 0
kedit -10
wily-20
axe -30
nedit -40
sam -50
sex -60
xcoral -70
xwpe-80
xemacs -100
Note that both by rationale and list, vim should be *higher* than nvi,
but it's not. (It's should also be higher in the vi alternative, and
it's not.) I don't know whether the vim maintainer of the time decided
to ignore the list, or quite possibly simply didn't get added to the CC:
list.
Also, I'd raise nano to 45
I honestly don't think this needs to go into policy, except perhaps
as an adjunct file. I'm willing to create this file and coordinate
additions and removals. If we do that, can we move this discussion
to (only) debian-policy (which seems like the right list, even if it
doesn't belong in the main policy document)?
Regards,
Steve
Bug#36151: REJECTED] /etc/init.d scripts should specify an explicit PATH
On 21-Jun-00, 13:17 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: Brock Rozen suggested that init.d scripts should have explicit PATH=... settings. No-one commented on the idea. As I recall, there was a lot of discussion...although maybe it occurred in -devel before Brock formally proposed it. So should we close this bug and put this requirement/suggestion into the coding guidelines (which may, one day, be written)? I think the guidelines is a better place for this than policy. Steve
Re: 'editor' alternative policy?
On 22-Jun-00, 17:54 (CDT), Jordi Mallach [EMAIL PROTECTED] wrote: Woo, thanks for the info. I tried to find something, but in that message pool it's difficult. It wasn't on any of the debian-* lists, just cc'd among the editor maintainers. That would be great, but I see a problem if we don't define a mechanism to work out these priorities, how should maintainers packaging a new editor decide on a number? Asking -devel? Well, I'd like to believe that maintainer packaging a new editor could look at Dale's rationale and the current list and say maxedfoo belongs at N and send me (or whoever's maintaining the list) a note and I'd add it. If I disagreed strongly, I might converse with the maintainer, or bring it up on -policy (or other agreed upon list). I'm not thrilled with the idea of formulas...they seem to say that the various maintainers can't be trusted to do the right thing. (For example, in the original discussions, we had various maintainers urging *lower* priorities for their editors, because they felt the editor wasn't particularly well suited as a standard. In fact, I wouldn't mind revisiting the idea that the vi clones should be ranked much lower. Anybody who want vi is going to type vi; somebody who is so new to unix that they type editor probably ought to have something a little more friendly, like nano or ee or ae. (For the record, I maintain nvi, *like* vi, and thing the pico/nano interface is hideous. But I know which one has a better chance of being successfully used by a complete newbie...assimilation can wait!) Anyway, I'll format the rationale/list and submit it to the powers that be. Steve
Re: 'editor' alternative policy?
On 22-Jun-00, 20:15 (CDT), Carl R. Witty [EMAIL PROTECTED] wrote: Steve Greenland [EMAIL PROTECTED] writes: In fact, I wouldn't mind revisiting the idea that the vi clones should be ranked much lower. Anybody who want vi is going to type vi; somebody who is so new to unix that they type editor probably ought to have something a little more friendly, like nano or ee or ae. (For the record, I maintain nvi, *like* vi, and thing the pico/nano interface is hideous. But I know which one has a better chance of being successfully used by a complete newbie...assimilation can wait!) I definitely agree that vi should be lower ranked. I don't care so much about the people who type editor; I worry more about people who try to use bug, or who accidentally hit 'v' when using less, etc. Yes, although I'll the easy way out of this one is to set the VISUAL or EDITOR environment variables, which should be within the capabilities of someone using reportbug (much better than bug!) or less. p.s. IANAD On a completely different topic, I've been seeing this pop up more and more often lately. If, as I assume, it stands for I Am Not A Developer, I find it a little disturbing that people feel the need to state it, as if it makes there opinions inherently less[1] valuable, or that they think someone is going to challenge them on that basis. A good idea can come from anyone, and I think that Debian has promoted that through its history by making all[2] of our decisions out in the open, with input from both developers and non-developers. I do not want to see that change. Steve [1] or, perhaps, more :-) [2] Okay, almost all, given the existence of debian-private. I guess you'll have to trust me that 99% of the traffic on that list is dreck.
Bug#65764: changelog shouldn't be in the copyright file
On 17-Jun-00, 22:57 (CDT), Brian Mays [EMAIL PROTECTED] wrote: [wrt content of README.Debian] Yes, but it should be general information of this type. I think that a detailed list of changes to the upstream source does not fit in here. When I see README.Debian, I immediately assume that this is where the maintainer has included information such as warnings about unusual ways that the program has been built for Debian or how the Debian package might differ from the way other distributions (perhaps even the upstream developers) build and package this software. I don't expect to see details about changes to the source. Furthermore, unless the Debian package is really special and the Debian package differs significantly from similar packages distributed from other sources, I don't see the need for a README.Debian file at all. It may be that we agree about the content of the README.Debian file: I think that what you're calling a detailed list of changes to the upstream source I would call package.diff.gz :-). Therefore, in summary, the copyright file contains the following information: (1) who owns the software, (2) the modifications that we have made to the upstream version of the software that we are distributing, and (3) the conditions by which a modified version of the software may be distributed. These three things seem to go well together. In fact, the more that I think about it, the more convinced I become that Ian Murdock and the early Debian developers got it right, and the format of the copyright file makes good sense. Ok, it begins to make sense to me to the content you describe belongs in one file. I'm not sure I like the name copyright, but changing it at this point would be silly. When the license is indeed included in the copyright file (for a nonstandard license), it forms an additional section at the end of the file, a section in which the license has been copied verbatim into the file. We are not modifying the document at all. At least, we are not modifying the content of the document. I don't really think that, just because the document no longer occupies its own file, we have modified the document in a significant way. Well, I guess my point was that we try our best to make sure that what we deliver as package.orig.tar.gz is md5sum identical to the original upstream distribution, and my opinion was that we ought to do our best to treat the original copyright/license file the same. Given that most of our licenses are GPL/BSD/Artistic (and thus become references), or must be extracted from source code, then my concern is probably unfounded. All of which leads to a resounding whatever with regard to this proposal... Steve
Bug#65764: changelog shouldn't be in the copyright file
On 16-Jun-00, 14:32 (CDT), Brian Mays [EMAIL PROTECTED] wrote: I have always considered the copyright file as the place to go when one needed to determine what has been done to the upstream sources by the Debian maintainer. (In one sense, it is a summary of the .diff.gz file). It is certainly easier to get that information from the text that is supposed to be recorded in the copyright file than it is to wade through pages and pages of confusing changelog entries. I agree that the summary should not be part of the changelog, but it never made sense to me that it was in the copyright file, either. The obvious place to me would be README.Debian. One of the problems with putting it in the copyright file is that for packages that don't use one of the common licenses, you have to modify the upstream copyright file, which feels like a bad thing to me. Steve
Bug#64437: PROPOSED] Must/Should/May in policy
On 23-May-00, 11:32 (CDT), Josip Rodin [EMAIL PROTECTED] wrote: On Wed, May 24, 2000 at 01:07:12AM +1000, Anthony Towns wrote: - Packages can and should place scripts in + Packages may place scripts in tt/etc/init.d/tt to start or stop services at boot time or during a change of runlevel. These scripts should be named tt/etc/init.d/varpackage/var/tt, and they Leave the `should'. So a normal bug should be filed against dpkg because it doesn't place a script in /etc/init.d to start or stop services at boot time or during a change of runlevel? dpkg? I thought this refers to the relevant packages... maybe it would be better to say something like: Packages that include daemons for system services should place scripts in tt/etc/init.d/tt to start or stop services at boot time or during a change of runlevel. What about daemons that are run only from inetd? Are we going to expect them to provide a standalone mode as well? Steve
