Bug#555979: debian-policy: Symlinks pointing beyond the root of the file system
On Sun, Nov 23, 2014 at 01:25:50PM +0100, Bill Allombert wrote: On Sun, Nov 23, 2014 at 01:58:41AM +, Anthony Towns wrote: On Sat, Nov 22, 2014 at 12:39:44PM +0500, Andrey Rahmatullin wrote: On Thu, Nov 12, 2009 at 04:31:52PM -0800, Russ Allbery wrote: Lintian has a tag: Tag: symlink-has-too-many-up-segments Severity: serious + Symbolic links must not traverse above the root directory. This isn't listed in https://release.debian.org/jessie/rc_policy.txt I don't see any reason why it should be RC; so s/must/should/ IMO. Is it your position that an issue that cause the FTP masters to reject the package at upload time is not necessarily RC ? Yes; or more particularly, that FTP masters should reject packages with any bug that's easy to fix and easy to detect with no (or very minimal) false positives, whether it's RC or not. Cheers, aj -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141123224220.ga29...@master.debian.org
Re: Bug#555979: debian-policy: Symlinks pointing beyond the root of the file system
On Sat, Nov 22, 2014 at 12:39:44PM +0500, Andrey Rahmatullin wrote: On Thu, Nov 12, 2009 at 04:31:52PM -0800, Russ Allbery wrote: Lintian has a tag: Tag: symlink-has-too-many-up-segments Severity: serious + Symbolic links must not traverse above the root directory. This isn't listed in https://release.debian.org/jessie/rc_policy.txt I don't see any reason why it should be RC; so s/must/should/ IMO. for symlinks that contain so many ../ segments that they traverse above the root of the file system. This tag is currently used by ftpmaster to reject uploads, but this behavior is not explicitly prohibited by Policy (although it violates both shoulds in 10.5). Violating a should in policy means it is prohibited... Cheers, aj, thinking policy should just drop the must distinction entirely... -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141123015841.ga8...@master.debian.org
Re: init system policy
On 16 November 2014 23:28, Anthony Towns a...@erisian.com.au wrote: Hi *, I've drafted up a document that I think matches reality on how init systems work in Debian. It's at: https://github.com/ajtowns/debian-init-policy and in (hopefully) easy-to-read pdf format at: https://github.com/ajtowns/debian-init-policy/releases/download/2014-11-16-1/init-policy.pdf Updated with various suggestions: https://github.com/ajtowns/debian-init-policy/releases/download/2014-11-18-1/init-policy.pdf Cheers, aj -- Anthony Towns a...@erisian.com.au
init system policy
Hi *, I've drafted up a document that I think matches reality on how init systems work in Debian. It's at: https://github.com/ajtowns/debian-init-policy and in (hopefully) easy-to-read pdf format at: https://github.com/ajtowns/debian-init-policy/releases/download/2014-11-16-1/init-policy.pdf It's in three sections -- what admins should know, what daemon maintainers should know, and what init-system maintainers should know. (The last section isn't actually written up) I think it probably makes sense for section 1 to end up as user docs, while section 2 and 3 should go into policy, but for the time being I wanted to get it all in one place to make it a bit easier to review, and make sure the advice to everyone is actually consistent. I've incorporated everything I think is relevant from current policy (in theory the git history shows what I dropped; might not be that easy to follow in practice). I've also included the status argument (bug#291148) for init scripts, and documented LSB-style status messages versus echo status messages. I'm not sure if it makes more sense to reincorporate it into the current policy document, or have it as a separate document. Seems like there are lots of independent policy documents these days (python, perl, etc), so maybe a good approach would be to compromise by keeping the separate policies as separate documents, but to package them all into debian-policy.deb... I've kept the musts to a minimum -- I think it makes sense to call things RC if they're going to deadlock the system or otherwise seriously confuse init, but everything else is just a regular bug (ie should). Happy to change that if the release manager's think something I've missed something crucial, but fairly opposed to severity inflation otherwise. Conversely, I've left a lot of things as should (or should usually) -- I think it's fair to call not supporting standard interfaces a bug, especially given that doesn't necessarily force anyone to work on fixing it. Anyway, corrections and additions appreciated; I'm not really an expert on init systems, so I've probably missed some bits. Upstart, and openrc and any other alternative inits could probably use some more info in particular. I had a quick go at trying to figure out what the deal with those was, but didn't really get anywhere. If anyone is up for giving a rundown of how the heck all the non-init systemd stuff (logind, systemd-shim, ...?) works when you're running a different init, that would probably be useful for the third section. There might be some bits where the rationale's not clear too. I figure I'll post a patch to get this added to -policy towards the end of the week; comments before then appreciated. Either on this list or as issues (or pull requests!) in github would be best, I guess. Cheers, aj -- Anthony Towns a...@erisian.com.au
Re: Phoning home
On Mon, Feb 25, 2008 at 04:25:28PM -0800, Steve Langasek wrote: On Mon, Feb 25, 2008 at 10:16:29AM +0100, Giacomo A. Catenazzi wrote: Speaking as a human being, I would suggest that Debian policy should be that all phoning home MUST be enabled explicitly, and MUST be turned off by default. should here would only mean that we've failed to correctly define phoning home. So that'd be something like Packages should not communicate on the network except as specifically necessary for their functionality. In particular they must not `phone home' by contacting a central service to report user statistics back to the author, unless the user specifically enables that option. ? Cheers, aj signature.asc Description: Digital signature
Re: priorities
On Mon, Dec 10, 2007 at 05:38:50PM +0100, Marc 'HE' Brockschmidt wrote: We have: required/essential -- stuff that can't be removed: libc, dpkg, etc important -- the rest of base, stuff necessary to bootstrap and recover a usable and useful system I have to admit that I don't see why we can't merge those two. At the moment, these packages are in required without being marked as essential: debconf For debootstrap, any package (that can be) pre-depended upon by an important package must be required. debconf-i18n dselect e2fslibs gcc-4.2-base initscripts libacl1 libattr1 libblkid1 libc6 libcap1 libcomerr2 libdb4.3 libdevmapper1.02.1 libgcc1 liblocale-gettext-perl libncurses5 libpam-modules libpam-runtime libpam0g libselinux1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libuuid1 lsb-base makedev mawk passwd procps sysv-rc tzdata zlib1g I don't see what makes those required-but-not-important or why the packages in important aren't required. Those are all depended on by essential packages... Cheers, aj signature.asc Description: Digital signature
Re: priorities
On Thu, Dec 06, 2007 at 11:03:08PM -0600, Manoj Srivastava wrote: Frankly, I suggest we look at the list of Unix commands as specified by the SUS -- which can also be seen at: http://en.wikipedia.org/wiki/List_of_Unix_programs So -- how many of the standard unix commands as defined by that page are not part of the standard section? I guess one of the the things I wonder every now and then is whether we really should be keeping standard as implying a ... traditional/historical/whatever Unix system, with pr and lpr and tcsh and bc and dc and whatever else that people would traditionally expect, instead of moving them to a task that can be installed only by people who actually know what they are, and then making sure we provide a real Unix system in that case. But by the looks of things there's still not much need for a change there, at least at this point. Cheers, aj signature.asc Description: Digital signature
Bug#432564: Allow debian/rules to not be a makefile
On Tue, Jul 10, 2007 at 01:42:03PM -0700, Don Armstrong wrote: On Tue, 10 Jul 2007, Russ Allbery wrote: I also could have sworn that we recently tightened this requirement, but I can find no mention of that in changelog with some quick searches. Am I just imagining things? It was tightened about 2 or 3 years ago, iirc. See the previous policy bugs for this issue, 88111 and 148941: It'll have happened during Manoj's incorporation of the packaging-manual into policy. See 72949. You'll notice you seconded it... :) -- http://lists.debian.org/debian-policy/2001/03/msg00020.html While they might seem old enough to have been lost in history, they were only actually closed in April last year... Regardless, even requiring debian/rules to be a makefile doesn't actually do much, because someone could do something like: .DEFAULT: debian/irule $@ or whatever. People should be using make, but if they have a valid reason for doing something else, policy shouldn't get in the way. And policy doesn't get in their way, because they can just do the above... Benefits of using a makefile include (as discussed in the previous bug reports), Also the debian/rules VAR=VALUE ... syntax is used by dpkg-buildpackage. debian/rules [variable=value ...] target [variable=value ...] exit: 0 if OK, non-0 otherwise debian/rules -q target exit: 2 if target cannot be built (doesn't exist), non-2 otherwise It looks like there was more in the thread than the bug log. Cheers, aj signature.asc Description: Digital signature
priorities (was: Re: RFC: cups as default printing system for lenny?)
Kind of reviving an old thread, but anyway: On Sun, Nov 11, 2007 at 07:12:35PM +0100, Marc 'HE' Brockschmidt wrote: I believe it to be one of the more important bits of a standard Unix *desktop* installation - but this just reminds me of the fact that I'm quite uncomfortable with keeping a system like package priorities around for much longer. Diverging use-cases (like in this case) show that one definition of standard isn't really helpful anymore. Haven't we more or less already moved away from priorities as meaning anything particularly important? We have: required/essential -- stuff that can't be removed: libc, dpkg, etc important -- the rest of base, stuff necessary to bootstrap and recover a usable and useful system standard -- a minimal collection of useful stuff we'd like to see on every Debian system optional -- all the good software in the world extra -- obscure stuff All the really important questions are which bits of optional (and occassionally extra) are useful for a given user. I'm not sure if there's any point to continuing to try to make sure that nothing = optional conflicts with anything else = optional. I think we may want to start thinking about getting rid of the whole thing and switching to something which allows us to express more complex importance measurements for packages. In fact, d-i and its task system have been a step in that direction, so we maybe should evaluate if we want to formalize it a bit more and get it into policy to replace priorities. required and important are both needed by debootstrap, so can't be gotten rid of (though they could be changed to use some other field/name). Priority: standard currently contains: at, bc, dc, lsof, file, less, sharutils, strace dnsutils, ftp, host, ssh, mtr-tiny, finger, w3m, whois doc-debian, doc-linux-text exim, mailx, mutt, procmail, mime-support, mpack gettext-base, locales pciutils perl (not just perl-base), python reportbug selinux policy That seems a pretty reasonable set of functionality to put on all Debian boxes (unless the admin specifically says otherwise), afaics. It might be sensible to replace ftp with lftp these days, though. And I'm not sure what happened to the exim v postfix defaults discussion a little while ago, and maybe procmail/mpack aren't all that necessary. It also includes, but afaics, probably doesn't need to (anymore): ispell, dictionaries-common, iamerican, ibritish, wamerican m4, texinfo (???) mtools (access unmounted msdos filesystems, not NTFS though) nfs-common, portmap (enables mounting NFS shares) pidentd (is IDENT still used on today's internet, with all its NAT?) openbsd-inetd (needed by pidentd) tcsh (people who remember what it is know how to install it) time (???) telnet (netcat is important, as is wget) But as far as default installs for anything of any real meaning, I just don't see Priorities as being relevant anymore. Cheers, aj signature.asc Description: Digital signature
Bug#432564: Allow debian/rules to not be a makefile
On Thu, Dec 06, 2007 at 06:31:50PM +0100, Lo?c Minier wrote: On Thu, Dec 06, 2007, Anthony Towns wrote: Regardless, even requiring debian/rules to be a makefile doesn't actually do much, because someone could do something like: .DEFAULT: debian/irule $@ or whatever. People should be using make, but if they have a valid reason for doing something else, policy shouldn't get in the way. And policy doesn't get in their way, because they can just do the above... Except it completely breaks any hope to benefit of this new Policy requirement: Uh, this isn't a new policy requirement. It's been a MUST in policy for years before you even applied to be a DD, eg. - passing -j2 might not be honored (Policy doesn't require it anyway) - querying the list of targets (to check for build-arch for example) with a make flag wont work either (Policy doesn't require it anyway) That's true -- but at least by specifically hacking your way out of make land by something like the above, it's clear that it's your job to make those features work. It'll partially honour those things too, eg make -j2 binary-indep binary-all will run both targets at once. As opposed to writing debian/rules as a #!/bin/sh script and then wondering why people are invoking it with weird flags, multiple targets, or variables as parameters instead of in the environment. Cheers, aj signature.asc Description: Digital signature
Bug#402975: debian-policy: Introduce a requirement for internationalisation of debconf templates
On Wed, Dec 13, 2006 at 10:33:51PM +0100, Christian Perrier wrote: + Packages which use the Debian Configuration management + specification must allow for translation of their messages + by using a gettext-based system such as the one provided by + the packagepo-debconf/package package. I'm perfectly aware that this introduces a must without doing it a should before, which is probably not very common practice. However, given the low impact of this change after two NMU campaigns on existing packages to make them switch to po-debconf, this would indeed be possible, in my opinion. I'd suggest should along with the use of usertags to track bugs that aren't fixed, and regular NMUing to make sure the issues actually get fixed as necessary. I'm strongly in favour of having proactive translation and QA teams that track classes of problems independently of the release team and make use of NMUs and similar to ensure they're consistently fixed across the distribution. I think we've got the technology and the ability to handle that without using the must/RC-severity stuff and bothering the release team. Cheers, aj signature.asc Description: Digital signature
Re: First draft of review of policy must usage
On Sat, Oct 28, 2006 at 12:58:34PM -0700, Russ Allbery wrote: If a csh script does not start with /bin/csh (or name some specific csh implementation; maybe there's an opportunity for wording improvement) or doesn't depend on c-shell, it's broken and won't work on a Debian system. That sounds rather RC to me. If it were the only thing in a package it would be grave, but if it's just a random script no one actually uses, it would just be a minor/normal bug, afaics. Cheers, aj signature.asc Description: Digital signature
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
On Fri, Oct 27, 2006 at 10:01:26PM -0500, Manoj Srivastava wrote: The technical committee charter and the policy process both adopt the principle that the people making the change [..] only act in an editorial capacity -- reviewing changes and committing them appropriately, but not do actual design work in their formal hats. But they also take the lead in discussions, and can and do decide if there are opposing opinions as to which opinion carries the day. Part of taking lead in the discussion is having the ability to say Stop, we have heard all arguments on this already, based on the current positions of people on the list, this option is what we shall decide to do.. Agreed absolutely. The only point I'm emphasising is that you don't just have to hear the arguments, you have to ensure they're made somewhere that others can hear them too. Understand this: the old policy process proposal was written in this atmosphere. If you read back in the archives, you'll find that I did mention back in those days (and often later as well) that we had to walk softly, since we had no real constitutional authority to be changing at all. Okay, that seems pretty clearly an untenable situation. Since there was no authority for a moderator, the process was overly bureaucratic. My assumption had always been that the maintainers of debian-policy would act as moderators. You said on IRC yesterday that you'd consider treating the current discussion as pre-proposal stuff, and follow the proper process once a conclusion was reached -- that sounds fine to me, but continually reserving the right not to do the BTS dance doesn't. If the process isn't suitable for the policy editors, it should be changed for everyone, rather than a short cut setup for the delegates/editors/ctte. The old process, meant for pre delegation days, really should be revised. It is not really followed in practice a whole lot, to be honest. It was followed while bugs were actively incorporated into policy; iirc that stopped for a while, and never really resumed. I couldn't say what the correct process for getting a change into policy would be now (well, two weeks ago), beyond post to -policy, and talk to Manoj. The stress should be on review, rough consensus, input from domain experts, sane, _contained_ discussion, and technical correctness being the goal, not popularity of opinion. The old process did not really ensure any of this (apart from a nebulous consensus as a goal.) Absolutely, though consensus should still be a goal, of course. I never said there will be no review. Indeed, since I am conducting this process, the review has to be even more strict -- I dare not abridge discussion nor decide what is expert testimony as readily as I would in a discussion I was not involved in. I don't think that's a desirable situation either; if a policy delegate wishes to put forward a change, a different delegate should be around to moderate discussion appropriately. In the old days, I had no authority to overrule even a single objection. Now I think that Debian has changed -- no matter what the issue, you can probably find a handful of very vocal people to block it. Heh. So does something like the following sound plausible? 1. Trivial policy updates that don't change the substance of policy (markup changes, fixing typos) will be made by the policy maintainers as they see fit. 2. Other changes will have a patch submitted against a bug assigned to the debian-policy package in the BTS, and forwarded on to any developers specifically affected by the proposed changes. 3. Once three developers or one of the policy maintainers (other than the proposer) have indicated they support the proposed change, the bug can be tagged confirmed, and will then be reviewed by the policy maintainers as a group. 4. If the policy maintainers are satisfied with the proposed change, the patch will be committed to the policy revision control system and the bug will be tagged pending. 5. If at any point the policy maintainers are not satisfied with the proposed change or the reasoning behind it, they may make suggestions tag the bug wontfix, and/or close the bug. 6. Policy should be designed to meet the concerns of all developers, and all suggestions should be taken into account as far as possible. That has a single process that applies to everybody, seems reasonably quick for changes the maintainers propose, works even if there's only one active policy maintainer, and requires at least one person other than the proposer to review every change. I'd suggest closing bugs that have been open for too long or seen too much discussion with a message like If this change is still desired, please open a new bug with a brief summary of discussion to date and the latest proposal.
Re: Policy delegation
On Tue, Oct 24, 2006 at 11:27:47PM -0500, Manoj Srivastava wrote: Given that there is no delegated power to change the technical policy, I can only see that the technical policy may be changed by a GR, or by the technical committee. 6. Technical committee I think you're mistaken, and that policy maintenance comes under the usual powers of the individual developers maintaining policy, namely section 3.1 (make any technical or nontechnical decision with regard to their own work). But you're the secretary, so on constitutional interpretation your word's final. So the policy editors have no right to upload any new manual, unless the constitutional issues are clarified by the project. As per that interpretation, I've added a REJECT for uploads of debian-policy. I won't be looking into formally creating a new delegation 'til after etch has released, at which point I hope we can find at least four people who'll be active in maintaining policy according to the policy process we've had for quite some time. Since it would be unfair of any one who has write permissions to the policy All developers have the ability to upload new versions of policy (or at least did, prior to the REJECT). Or, perhaps, the tech ctte can directly take over the policy manual, as provided for by the constitution. Maintenance of the policy manual is designed to be a lightweight task that doesn't require significant creative or editorial judgement (that being exercised in the drafting and discussion of proposed changes prior to the actual inclusion), that doesn't seem entirely out of the question should policy need updating prior to etch's release. Cheers, aj signature.asc Description: Digital signature
Re: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 09:20:34AM -0500, Manoj Srivastava wrote: The only normative words are MUST, SHOULD, MAY, and RECOMMENDED. I am considering using upper case where we expect conformance. Didn't the definitions of MUST/SHOULD/MAY get removed in your patch though? Cheers, aj signature.asc Description: Digital signature
Policy delegation
Hi, I'm withdrawing the Package Policy Committee delegation made by Branden in June last year, in: http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html That leaves debian-policy maintained by subscribers to the debian-policy mailing list, according to the process described by the policy-process document in that package. TTBOMK recent versions of policy have been maintained using arch as the revision control system of choice, and are available from: http://arch.debian.org/arch/private/srivasta/archive-etch/debian-policy/ Policy describes itself thus: This manual describes the policy requirements for the Debian GNU/Linux distribution. This includes the structure and contents of the Debian archive and several design issues of the operating system, as well as technical requirements that each package must satisfy to be included in the distribution. The policy-process document recommends that there be between 4 and 8 policy maintainers/editors, who do not have any special powers and in particular do not have any creative power nor act as a central control over the contents of policy. Anyone who would like to help maintain policy is encouraged and welcome to do so, following the guidelines in policy-process for proposing and uploading changes. Cheers, aj -- Anthony Towns Debian Project Leader signature.asc Description: Digital signature
Re: Automated testing - design and interfaces
On Fri, Nov 18, 2005 at 12:23:49PM +, Ian Jackson wrote: (Note: sorry about my earlier header mixup. This thread is on the wrong list so I'm crossposting this reply to -project and -policy and have set Reply-To to point to -policy. I will also quote more of Stefano's message than would usually be sensible, to give readers in -policy an easier time.) This isn't even implemented, so it can hardly be ready to be added to -policy; I think Steve was right in choosing -devel as the right list... Cheers, aj signature.asc Description: Digital signature
Re: Bug#224509: [PROPOSAL] Correct spurious promise regarding TTY availability
On Sat, Dec 20, 2003 at 02:23:36AM +0100, Tore Anderson wrote: Well, I considered submitting this bug on dpkg instead of policy. However, statements from the policy editors on numerous occations have given me the impression that policy seeks to document current practise, not enforce changes. Yes, and current practice is that a controlling terminal is required... Hence, as dpkg does not check for /dev/tty availability, I think it is policy that should change, not dpkg. dpkg doesn't check that all Essential: yes packages are installed, either. Which is to say, just because dpkg doesn't check some condition, it doesn't mean that other packages will continue working if you violate it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgprZVnIgMOrX.pgp Description: PGP signature
Re: Should we allow packages to depend on packages with lower priority values?
On Mon, Dec 08, 2003 at 03:17:19PM +0100, Marc Haber wrote: Let A and B both be packages that provide virtual package C. A is the default C in Debian, and is therefore Priority: important. A depends on E and F, which must be Priority: important as well, as required by current Policy. Now let's look at a system where the local administrator has decided to use B instead of A. Since E and F are Priority: important, dselect happily proceeds to install E and F on the system, even if they are not needed since the system in question uses B instead of A. Now let's consider what happens if they've already installed the system, with A, and hence E and F. The run dselect, or apt-get, or even dpkg, and install B, remove A and are left with B, E and F. If that's not what's desired, your dependencies are wrong. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgp3aIS5qijU2.pgp Description: PGP signature
Re: Colons in upstream version.
On Sat, Nov 01, 2003 at 02:51:48AM +0200, Richard Braakman wrote: On Sat, Nov 01, 2003 at 01:19:51AM +0100, Josip Rodin wrote: On Sun, Oct 26, 2003 at 01:53:26PM +0100, Bernhard R. Link wrote: Policy 5.6.11 describes the upstream version part as: | if there is no epoch then colons are not allowed. ~ Thus I suggest 5.6.11 to be changed so that colons are no longer allowed Please read and reconsider :) This just means that colons are _sometimes_ allowed in the upstream version (namely when the package already has an epoch for some reason). Having them sometimes allowed is even worse than having them always allowed, so it makes me support the proposal more strongly :) Huh? Upstream versions can only sometimes have -es too, big deal. I'd be more inclined to fix the tools, personally, or to say that within Debian, we'll translate upstream colons to something else than removing the support from dpkg or changing its meaning. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgpOG8oKWko5Y.pgp Description: PGP signature
[EMAIL PROTECTED]: FHS 2.3 beta]
- Forwarded message from Christopher Yeoh [EMAIL PROTECTED] - From: Christopher Yeoh [EMAIL PROTECTED] Subject: FHS 2.3 beta Date: Thu, 11 Sep 2003 11:30:40 +1000 To: Lsb-Discuss [EMAIL PROTECTED], debian-lsb@lists.debian.org X-Mailer: VM 7.17 under Emacs 21.3.2 A beta release of FHS 2.3 is now available. The original announcment, together with diff is available here: http://www.samba.org/~cyeoh/fhs_2.3_changes.txt A PDF of the beta can be downloaded here: http://www.samba.org/~cyeoh/fhs-2.3-beta.pdf Please send any comments to [EMAIL PROTECTED] or directly against the bug database at http://bugs.freestandards.org Chris -- [EMAIL PROTECTED] IBM OzLabs Linux Development Group Canberra, Australia - End forwarded message -
Re: what is policy about?
On Wed, Aug 27, 2003 at 04:50:29PM -0400, Sam Hartman wrote: For example if the release team did not add some requirement because they didn't believe it was a best practice, I would find that problematic. Let's rephrase that to be even simpler: if there was something in policy that the release team didn't thing was best practice, that would be problematic. That's true as long as the release team consists of people who're fairly clueful about packaging, and applies to any other group that's fairly clueful about packaging, too. What I'm claiming is that having things that are considered best practice be written down in multiple places is counterproductive and confusing; as is mixing them up with things that aren't really about packaging at all. Basically I'm happy if things work together; I don't want a split of policy to turn into two competing visions of Debian. I especially am uncomfortable with two competing visions of Debian when one of the visions is controlled by a roughly consensus-based process, but that one that matters is controlled by a small cabal. Uh, yeah, *that*'s constructive. You do remember that we tried getting RC policy to be controlled by -policy, and it didn't work, right? Too many things that shouldn't be RC getting made RC, too many things getting made RC by accident or default, too much effort required to convince people that their pet fancy shouldn't be RC, and the RC policy not being up to date enough when it counts, and all. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpUIkasUDfTj.pgp Description: PGP signature
Re: what is policy about?
On Tue, Aug 26, 2003 at 02:02:44PM -0400, Sam Hartman wrote: I'd see it as a problem if there were some best practice in policy that was implemented by a good fraction of the packages but the release team were not willing to accept that practice as a release requirement. Nope, no chance of that. Release requirements are the _bare minimum_ requirements that package must satisfy. The simplest counter-example is documentation. It's certainly best practice to write good user documentation for all our programs and packages. While we mightn't be there yet, I'd certainly hope that one day more than just a good fraction of packages have good documentation. But nevertheless, I expect we'll still be willing to accept new, undocumented or poorly-documented packages in Debian when they have useful new features that aren't otherwise available. Sure, not having documentation is still a bug, and it should be filed and fixed, but that's a _far_ stretch from not being willing to make the package available to users. Again: there is _no_ need to think of policy as a stick to beat people over the head with. We're _all_ sensible people who want to make Debian the highest quality software distribution in existance, even if we might disagree on how to go about it. We don't need to coerce people with threats for every trivial little thing, and it's probably actively harmful to try to do so. Policy's at its best when it simply says what should be done, and explains why doing other things isn't as good; not when it declares such-n-such must be done, lest the wrath of the release manager descend upon you all. Is having documentation for all your programs Debian best practice? Is it Debian's policy to have documentation for all programs? Does Debian require all programs to have documentation? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpzXqkFS2QSr.pgp Description: PGP signature
Bug#207132: debian-policy is missing gcc transition plans
On Mon, Aug 25, 2003 at 12:26:16PM +0200, Josip Rodin wrote: http://people.debian.org/~rmurray/c++transition.html Ps: you might want to consider retiring the libc6 transition document. I'd rather if we dropped all such transitional issues from the Policy manual. They're just bother and don't really have to be here to be mandated by the project (examples abound -- libc6-migration, fhs migration, C++ 3 transition...). The technical committee can make a statement and be done with it. I'd rather we stopped looking at policy as mandating things. There are three things policy's trying to do at the moment: 1) specify technical standards, like version formats and package names 2) specify packaging and coding best practices 3) specify release requirements All these things are necessary if we want to maintain Debian as a highly integrated system -- people don't come to the project with the same expectations and experience, and we don't want to inflict the same mistakes on our users in perpetuity as new developers come along. http://people.debian.org/~ajt/sarge_rc_policy.txt is a good start at separating out (3), and I'm happy for the release team to continue maintaining that, even though it obviously is a little redundant wrt policy. (1) is easy to separate out -- there's only a couple of sections that specify APIs and formats rather than implications, mostly from the old packaging manual. That leaves (2) though, which really includes things like transition documents, and subproject policies, and most of the current debian-policy document. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgp8ZZlt10wZC.pgp Description: PGP signature
Re: Bug#207132: debian-policy is missing gcc transition plans
On Tue, Aug 26, 2003 at 12:50:53AM -0500, Manoj Srivastava wrote: In my view, policy is supposed to represent the minimum set of rules that packages follow to allow the parts to dovetail together. I don't think that makes sense -- getting packages to dovetail together isn't something that can be achieved once and forever more; once we've got libraries and file hierarchies making sense and fitting together, we're not going to stop, we're going to start working on getting documentation put together in more consistent fashions, or stop Gnome from spewing assertions to xterms, or any number of other things. But doing any of that requires a document that's willing to cover all the things we're trying to achieve. Having many documents doesn't work, because packagers coming to Debian need to be able to find *everything* that affects them; having stuff undocumented doesn't work because otherwise not only won't new people know it, but those of us who decided what we'd do are liable to forget. The developers reference is the best repository of best practices -- common techniques that over time have been discovered to be desirable to adopt. No, it's not. The developer's reference is about procedures; debian policy is about packaging. And this is utterly appropriate; working out what to do (packaging policy), and how to do (uploading policy) are fundamentally different things. Procedures, like when to upload NMUs or the use of DELAYED queues, change by dictate and mood; technical policy whether you consider that best practices change only when new problems are noticed, or when new procedures become possible. Moving these things into other documents is a *mistake* -- it was a mistake when we did it to the packaging manual, one which continues to make policy confusing and difficult to follow, and it's a mistake to extend chapter six of the developers reference. [...] but by and large, the goal is to pare it down to a ruleset _required_ for packages to interact and integrate tightly together. What, exactly, do you think this means? It's not required in the sense that the package won't be allowed in Debian, or in a Debian stable release; that's http://people.debian.org/~ajt/sarge_rc_policy.txt. It's not required in the sense that the packages won't work at all, or even that it won't work for the majority of people; that would be even shorter than the sarge_rc_policy. I, however, agree that policy is not a stick to beat developers on the head with, which is another way of stating what you said. The Axiom of Choice is obviously true; the Well Ordering Principle is obviously false; and who can tell about Zorn's Lemma? (You did just disagree with me, then restate my comment and agree with it, right?) If you're not going to beat people on the head with policy, the only merit it has *at all* is as a compendium of well thought out advice to package maintainers about how to do their work. That is the *precise* definition of best practices documents. By contrast, sarge_rc_policy is a list of requirements, and is something to beat people over the head with. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpRzo5ld1LpH.pgp Description: PGP signature
Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting
On Fri, Aug 22, 2003 at 07:46:56AM +0200, Christian Perrier wrote: This proposal is what I think to be the next step : make this a must This won't be happening for sarge. If you want it to happen, please focus your efforts on finding packages that don't do it, and supplying patches to add the features instead. Cheers, /\_ aj -- wearing Release Manager hat -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgplfCJPMYIN3.pgp Description: PGP signature
Bug#172436: Security concerns regarding browser proposal
On Mon, Aug 04, 2003 at 08:56:23AM -0400, Matt Zimmerman wrote: In making it safe, you are no longer implementing esr's specification. It will break on nontrivial cases, such as the -remote commands for netscape: BROWSER=netscape -raise -remote \openURL(%s, new-window)\:lynx Wouldn't something like $ BROWSER=/usr/bin/netscape-remote or $ BROWSER=/home/aj/bin/browser $ cat /home/aj/bin/browser #!/bin/sh if [ $DISPLAY ]; then galeon $1 else lynx $1 fi make more sense and be simpler (ie, having programs invoke BROWSER directly)? Wouldn't it then make more sense to have /usr/bin/sensible-browser be used when BROWSER is unset, and have that do a slightly cleverer check of which browsers are available? (alternatives-based using text-browser and x11-browser and some fallbacks, maybe?) Certainly that's more in line with how we handle EDITOR and such at the moment. Use of $BROWSER is then: char *browser = getenv(BROWSER); if (!browser) browser = /usr/bin/sensible-browser; execl(browser, browser, url, NULL); And security is a matter of ensuring sensible-browser, x11-browser and test-browser can all handle arbitrary, unchecked input as $1. This can probably be managed by either (a) checking that url doesn't start with -, or (b) using wrapper scripts so lynx-browser invokes 'lynx -- $1', eg, or (c) changing the execl line to: execl(browser, browser, --, url, NULL); Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpNh2thqZR6S.pgp Description: PGP signature
Bug#203650: Poor recommendation in dpkg-statoverride section
On Fri, Aug 01, 2003 at 02:05:02AM -0400, Joey Hess wrote: Andrew Suffield wrote: Hold that thought. We hashed out a few ideas on IRC; more in a few days. Meanwhile, let's assume it will be solved... anything else? I missed that discussion, but the obvious approach in fakeroot is user autovivification (to bottow a term from perl) on chown. Or getpwnam(), maybe? How that'd mix in with getpwent() might be confusing. Debian packages aren't necessarily built under fakeroot, though, so this can't necessarily be relied on. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpekTm1rRR1L.pgp Description: PGP signature
Re: Policy for 32-bit uids/gids?
On Wed, Jul 02, 2003 at 01:15:09PM -0500, Steve Langasek wrote: However, with the recent availability of 32-bit uids, this seems unnecessary. I would suggest allocating a 16-bit range out of the remaining (2^32-2^16) uids for Samba's use, and the same for gids; even something as small as 5000 uids should be ok, since admins always have the option of choosing a different range -- it's just a question of how useful the defaults will be to our users. Is there any reason it should be a statically (and hence globally) allocated 5000 numbers? Another way of doing it would be to have something like: /etc/reserved-uids 1:100 debian-static 100:999 debian-dynamic 1000:2 local 3:5 reservedA 6:64999 debian-static2 65000:65533 reservedB 65534 nobody 65545 reservedC 65536:7 samba The theory being that: adduser chooses a uid from the local block to do its thing samba chooses uids from the samba block to do its thing in your postinst, you ask how many uids may i reserve? with a default answer of (say) 5000, and add that to /etc/reserved-uids with some sort of update-reserved-uids tool Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpNqRjcSOuSU.pgp Description: PGP signature
Re: Modernising menu manual icons requirement
On Wed, May 14, 2003 at 07:53:19PM -0400, Joey Hess wrote: Of course you'll get better results in such scaling if you have more colors available. The problem, I think, is that some of the window managers that support icons, like fvwm, do not do scaling, or don't do it very well. Couldn't update-menus dump some pre-scaled icons into /var or /usr somewhere for such window managers? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!''
Re: Versioned Symbols
On Mon, Mar 10, 2003 at 10:47:40AM -0300, Henrique de Moraes Holschuh wrote: Agreed. As far as programs build on Debian systems won't run elsewhere, it is just a matter of pushing the versioning of said core libraries to the LSB, which shouldn't be too difficult if we do it right and send in patches. Uh, no, the LSB doesn't standardise every library that is shipped by every distribution other than Debian. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!''
Re: Versioned Symbols
On Sat, Mar 08, 2003 at 04:16:47PM -0500, Sam Hartman wrote: I think that we should implement versioned symbols. Uhh, versioned symbols means that programs built on Debian systems won't run elsewhere. That's not something we should be doing, except in very specific cases where the gain outweighs the drawback. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgptOckMPsbDE.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
On Mon, Dec 16, 2002 at 12:12:08PM +0100, Wichert Akkerman wrote: Previously Adam DiCarlo wrote: Well, before I venture on this, is there a way we can store certain data in control.tar.gz or something but without bloating the Packages file? No. Well, strictly, there obviously is: postinsts don't end up in Packages.gz after all. It doesn't make any sense for this though. It is relevant to the discusison though.. do we want to bloat the Packages file with usptream author homepage information as well? The Packages file is mainly meant to be all the information you should need to work out whether you want to install a package or not: description, what other packages you need, a file name to download, etc. A More-Info-URL: field might make sense here in that it'd let you find out more about the package, see screeenshots and so forth. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Australian Linux Lovefest Heads West'' -- linux.conf.au, Perth W.A., 22nd-25th January 2003
Bug#170019: debian-policy: Ambiguity in section 11.7.2 (Configuration files: Location)
On Thu, Nov 21, 2002 at 12:40:32PM +0100, Josip Rodin wrote: Frankly, it should be enough to simply mandate /etc for all configuration files, I don't know why we keep this exception for other directories. Technically, it's enough to mandate /etc, but suggesting the use of symlinks from /usr might make life a bit easier for some maintainers who are aghast at the thought of rewriting upstream to use /etc natively. *cough*143825*cough* Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Bug#167422: general: files in /usr/share should be world-readable
On Sun, Nov 10, 2002 at 11:26:31AM -0800, Thomas Bushnell, BSG wrote: /usr/share is not appropriate for that, as it is the OS's playground (and I can't see any use for the OS installing secrets there). For site-specific secrets /usr/local/share is a better choice. root users is not somehow not the OS. For example, root users store secrets in the shadow password files. I'm speaking of secrets that *OS* programs need to have, and which should be shared among cooperating machines. That doesn't particularly make sense. If the secret is distributed as part of Debian, it's not a secret -- anyone can buy their own copy of Debian, pull apart the debs and find out what it is themselves quite happily. So the secret has to vary between machines, which either makes it configuration info that's site specific, in which case it should go into /etc, or variable data maintained entirely by a program, in which case it should go into /var, or completely site-specific in which case it should go somewhere site-specific, like /home, /srv, /usr/local, etc. The contents of /etc and /var are allowed to be shared amongst machines, it's simply expected that which files get shared and how is more complicated than for /usr, since they're much more site-specific. For reference, $ find /usr \! -perm -004 $ Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Bug#167422: general: files in /usr/share should be world-readable
On Sun, Nov 10, 2002 at 10:02:42PM -0800, Thomas Bushnell, BSG wrote: One such thing that can be shared, but which should also be secret, is a nethack bones level file. That shouldn't go in /var, because it *should* be shared normally by a group of cooperating machines. Portions of /var are sharable: Here is a summarizing chart. This chart is only an example for a common FHS-compliant system, other chart layouts are possible within FHS- compliance. +-+-+-+ | | shareable | unshareable | +-+-+-+ |static | /usr| /etc| | | /opt| /boot | +-+-+-+ |variable | /var/mail | /var/run| | | /var/spool/news | /var/lock | +-+-+-+ If you want to share nethack bones files, you put them in /var/games/nethack, or similar, then share it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Bug#167422: general: files in /usr/share should be world-readable
On Sun, Nov 10, 2002 at 11:02:51PM -0800, Thomas Bushnell, BSG wrote: Still, I'm loath to create extra rules that we don't need. In general, yes, *every* file should be readable, and it's appropriate to file bug reports for the Debian packages which needlessly prevent files from being readable. But I don't think we should ensconse a rule here. We've already got that as a rule, anyway, see 11.9. Permissions and owners: Files should be owned by `root.root', and made writable only by the owner and universally readable (and executable, if appropriate), that is mode 644 or 755. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: Essentialness of awk
On Fri, Sep 27, 2002 at 03:49:09PM +0200, Santiago Vila wrote: Several years ago it was agreed that awk would be essential (which is currently implemented by a Depends: awk in base-files). Err, shouldn't base-files Pre-Depends: awk? (In effect, base-files is the Essential: yes package that provides the awk functionality (since mawk and gawk *aren't* Essential: yes), so it should use a Pre-Depends: to ensure that functionality is available even while base-files is unconfigured. I was going to propose a patch against the current policy document, but there is a little problem: Since dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state, all essential packages must supply all of their core functionality even when unconfigured. If the package cannot satisfy this requirement it must not be tagged as essential, and any packages depending on this package must instead have explicit dependency fields as appropriate. Since awk and gawk aren't tagged Essential: yes, I'm not sure this really applies. This paragraph was added to fix Bug#50832 but if we follow it strictly then all the awk packages are in violation, since they use the alternative mechanism to update the awk symlink in /usr/awk and therefore do not provide their core functionality until they are configured. Given that a /usr/bin/awk link is made available as part of the initial install, I don't think there's any way of it becoming unavailable even though alternatives are used. More to the point, I don't see why we should not be able to do the same with /bin/sh and bash/dash. Suppose bash version X includes /bin/sh in the .deb; bash version Y ( X), doesn't. # dpkg --install bash_Y*.deb foo*.deb bash Y is unpacked over the top of bash X; /bin/sh is removed if present since it's no longer in the package foo's #!/bin/sh preinst script is run, it dies horribly, dpkg aborts I think it's possible to avoid this by having bash Y's preinst dpkg-divert /bin/sh, and make a new symlink that's not controlled by dpkg in preinst, then unpack, then use update-alternatives in postinst. I actually thought that's roughly what bash was doing these days, but apparently not. Using dpkg-divert like that is probably fairly risky -- I'm not sure how it'll cope with the various things people are already doing to /bin/sh -- so you'd want to be fairly thorough working out how every possible case would be handled. As of today, is it still true that dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state? Why should dpkg unconfigure an essential package to begin with? apt-get will try to avoid it, dpkg won't. dpkg treats Essential: yes as don't let me accidently --remove or --purge it, it's only convention that lets us treat them as you don't need to specify a dependency on these packages. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpPkXgP60QdC.pgp Description: PGP signature
Re: Essentialness of awk
On Fri, Sep 27, 2002 at 06:09:13PM -0400, Joey Hess wrote: (The other special cases I am aware of are the daemon starting mess, which will be fixed by invoke-rc.d, some fairly unavoidable dpkg bootstrapping, some timezone thing, and an exim mess since it still doesn't use debconf.) The aim was to drop exim from base entirely to make the postfix and qmail types all happy. We missed that for woody, but we ought to be able to do it for sarge. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: Essentialness of awk
On Fri, Sep 27, 2002 at 09:59:25PM +0200, Santiago Vila wrote: What I mean is that the current policy wording about essential packages is sub-optimal. The important thing is not that essential packages work even if they are unconfigured, the important thing is that once they are configured (by debootstrap) they should not be unconfigured again. No -- they're unconfigured every time dpkg unpacks a new version. That's what unconfigured means. I think I understand what you're getting at, but I can't think of a way to say it. There's a problem that if there's a new required package then it has to fail to break any essential packages when you start unpacking and installing it. Mostly that can be handled by pre-depends: (for new libraries that essential packages need) and replaces: (for splitting essential packages), I think. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpwWiy808j8g.pgp Description: PGP signature
Re: Essentialness of awk
On Sat, Sep 28, 2002 at 01:53:58PM +0200, Santiago Vila wrote: I was going to propose a patch against the current policy document, but there is a little problem: Since dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state, all essential packages must supply all of their core functionality even when unconfigured. If the package cannot satisfy this requirement it must not be tagged as essential, and any packages depending on this package must instead have explicit dependency fields as appropriate. Given that a /usr/bin/awk link is made available as part of the initial install, I don't think there's any way of it becoming unavailable even though alternatives are used. Exactly, but still none of the awk packages will work when unconfigured (before they are bootstrapped), as policy seems to forbid. I don't really see what relevance policy has to bootstrapping in that sense; I mean, dpkg is unpacked before libc6 (they're done alphabetically initially, iirc) which violates a pre-depends, eg. Even essential packages are allowed to assume /usr/bin/awk works before they're installed, that the mawk and gawk packages happen to assume that fact in order to ensure that /usr/bin/awk continues working while they're unpacked is no great problem. # dpkg --install bash_Y*.deb foo*.deb bash Y is unpacked over the top of bash X; /bin/sh is removed if present since it's no longer in the package foo's #!/bin/sh preinst script is run, it dies horribly, dpkg aborts Indeed, but bash version Y (X) which does not provide /bin/sh in the .deb is, in some way, a step backwards as far as bootstrapping is concerned. It's no big deal either way. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Bug#162120: debian-policy: Deletion of configuration files--should it be preserved?
On Tue, Sep 24, 2002 at 09:05:12PM -0700, Thomas Bushnell, BSG wrote: I didn't say that it was the best way to go about things; even Manoj didn't say that. So you're saying bugs should be filed to encourage packages to choose a less optimal way of doing things than what currently happens? No, a perfectly reasonable alternative would be to change policy to match. I don't care which alternative is chosen. And, further, you don't actually care which is the best solution, but you're trying to sanctify it for future generations? Look everyone, the policy process failing as you watch! Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpa7xN7YvNv4.pgp Description: PGP signature
Bug#162120: debian-policy: Deletion of configuration files--should it be preserved?
On Wed, Sep 25, 2002 at 12:47:29PM -0500, Manoj Srivastava wrote: I fail to see a reason why we should over ride user changes whener we, the maintairners, feel a capricious whimsy to doso, even when we believe our way is the one true way, and the silly admin ought to know better than to meddle in the affairs of his betters. manoj trying to counter some rhetoric on this report If you're trying to counter some rhetoric, could you _please_ do it with something other than rhetoric of your own? No one is saying that rewriting your /etc/inetd.conf to remove all the local changes you've made is a clever thing to do. You're not arguing against people not preserving user changes in general, you're arguing against the specific case of reinstating removed configuration files. Now, you gave an example in another message that you might want to do that in creating a honeypot. I've no idea why you would -- removing the config file doesn't buy you anything (the daemon still starts, you can still start the daemon with other options if you either edit the config file or specify a different config file on the command line), and a better effect can be achieved by making it so you can remove inetd entirely (which was what the thread on -devel was originally about). If you need the same effect you would get by removing the file, you can simply clear it or comment everything else, which also has the benefit of the results matching your intuition (ie, inetd starts, and nothing happens). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Bug#162120: debian-policy: Deletion of configuration files--should it be preserved?
On Tue, Sep 24, 2002 at 11:11:20AM -0500, Manoj Srivastava wrote: justification: this is not a flaw in the policy, at best, this may be a proposal to change policy to codifying, in my opinion, a less desirable behaviour, and should be treated like any other proposal For heaven's sake, does someone have to disagree with _EVERYTHING_? Sorry, this is a bug in those packages. No, it is not. dpkg has always had the correct behavour of not reinstalling conffiles that are removed; and so do packages managing configuration files using ucf. That's really great. The reason some packages _don't_ use dpkg or ucf for managing their configuration files is because dpkg's and ucf's behaviour is _not_ always desirable. That's an utterly bogus line of argument, and an absolutely _meaningless_ one -- it's making policy for policy's sake rather than because it actually benefits anyone. Policy, while documenting practice for the most part, should not recommend or condone broken behavour just because packages are broken. The. Packages. Are. Not. Broken. It's that simple. How many times have you found base-passwd recreating /etc/passwd and /etc/group a nuisance? Never? Funny that. Why the fuck do we have to have a debate about this? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgp3dhOVdk7AK.pgp Description: PGP signature
Bug#162120: debian-policy: Deletion of configuration files--should it be preserved?
On Tue, Sep 24, 2002 at 07:54:15PM -0700, Thomas Bushnell, BSG wrote: We have to have a debate about it because there is an actual substantive disagreement between you and Manoj. Really? What is it? I only saw comments that amount to I interpret policy this way and other things do it this way, neither of which is a response to my original request for someone to give a good reason why randomly deleting config files of installed packages is the best way to go about things, and should be supported. If you don't think it's that important, then say so, and Manoj could put in a policy change to make explicit that deletions must be preserved. Well, I suppose I could change the scripts to cope, and change inetd to just enable all its internal services unless told otherwise, so anyone who was stupid enough to think removing the config file would do any good could get their machine DoS'ed off the .net thanks to a handful of untracable spoofed packets. Because, hey, personal whims, and the letter of policy are what matters, not the needs of our userbase, right? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpOq1UedMSBo.pgp Description: PGP signature
Bug#32263: Splitting CGI-BIN
On Mon, Sep 23, 2002 at 05:34:44PM -0500, Manoj Srivastava wrote: Have we decided on whether aj's proposed changes (below) are what we reached a consensus on? == /usr/lib/cgi-bin/ packages dump CGI scripts in here willy-nilly ~wwwdata/cgi-bin/ packages make symlinks to /usr/lib/cgi-bin/blah in postinst, based on some setting in /etc/ somewhere So that admins can just rm symlinks to scripts they don't need, or, if they want to be absolutely sure they don't get any cgi-bin scripts they don't want, change the config file. == Hmm. What happens if I remove a symlink, and then the package is upgraded? I'd assume what we'd want is for the symlink to stay removed. Something like: if [ $1 = configure ]; then if [ $2 = ] || dpkg --compare-versions $2 -lt 1.0.3-5; do # first install, or first install since support for update-cgi # added update-cgi --add /usr/lib/cgi-bin/foo fi fi should handle that, I think. Probably with: update-cgi --disable /usr/lib/cgi-bin/foo (which notes whether or not there was a symlink for foo somewhere and removes the symlink, for dpkg --remove) update-cgi --enable /usr/lib/cgi-bin/foo (which looks at the note, and recreates the symlink if appropriate) update-cgi --remove /usr/lib/cgi-bin/foo (which just removes the symlink) at appropriate places in the *rm scripts. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Bug#32263: Splitting CGI-BIN
On Fri, Sep 20, 2002 at 12:13:25AM -0500, Manoj Srivastava wrote: Would it not be a desirable goal to ultimately have the users using the /cgi-lib for system scripts, and /cgi-bin for local scripts, and have distinct name spaces? I don't see why? There are two reasons for name spaces: you need one so that packages can dump their files on the filesystem without having to worry about overwriting users' CGI scripts. You also need a namespace so you can decide which scripts are available for the webserver -- this might be a full hierarchy, effectively, if you're serving different web sites and want different CGI scripts available on each. I don't see any value to letting the guy browsing your website be able to tell the difference between local CGI scripts and remote ones though. It seems beneficial not to, even, so you can have replace your homebrew build of http://example.com/cgi-bin/analog with the prepackaged version, without having to do any work or put any thought into it. Maybe I don't understand the cases where you want to have a link to a CGI script in a package, though? Perhaps the real problem comes when dealing with subsystems that happen to be operated through CGI scripts -- linuxconf or similar things do that, don't they? I'm not really seeing any cases where that's a nuisance to deal with, but I don't use such things, so maybe that's where I'm missing something? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Bug#32263: Splitting CGI-BIN
On Thu, Sep 19, 2002 at 11:26:54AM -0400, Brian White wrote: What would y'all think about having cgi-bin managed more like, umm: /usr/lib/cgi-bin/ packages dump CGI scripts in here willy-nilly ~wwwdata/cgi-bin/ packages make symlinks to /usr/lib/cgi-bin/blah in postinst, based on some setting in /etc/ somewhere This has how I've done my site, but it's a pain. It's only a pain because at the moment you have to make the symlinks yourself, though, isn't it? Also, many webmasters run virtual websites and thus such symlinks would have to be done (or not done) for each webspace and that's not something can be easily automated. Hrm. If they want the same CGI scripts on all their web sites, it's easy, just point the cgi-bin alias for each vhost to the one directory. If they want fine-grained control over their CGI scripts (This client only gets access to any given CGI script when it's approved by the techies, and they pay $5), then it's not an issue, since they'll be making the symlinks by hand anyway. It's only when they want fine-grained control of local CGI scripts, but all the pre-packaged CGI scripts on each vhost, that we could do any better. Of course, if they _really_ want that, they could just setup the cgi-lib alias themselves. But I would've _thought_ the other two cases would be the common ones, though? Actually, fixing that'd be trivial too. Make your config file look like: ] $ cat /etc/cgi-scripts ] cgi-symlink-dirs=/var/www/cgi-bin /srv/foo.com/cgi-bin /srv/bar.com/cgi-bin and have an update-cgi script of some sort that does the parsing for you. You could be a little bit more fine-grained too, if that was worthwhile. Being able to easily disable a couple of prepackaged CGI scripts seems like a common enough behaviour to optimise for. Or maybe not, of course. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpOPMe1nVSfq.pgp Description: PGP signature
Bug#160776: debian-policy: [PROPOSAL] debconf spec updates to conform with reality
On Fri, Sep 13, 2002 at 11:46:59AM -0400, Joey Hess wrote: These modifications to the debconf spec simply make it conform to the reality of how some things work now. This is part of an effort to make debconf and cdebconf better substitutes for each other. Seconded. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Bug#160248: section 13.3 unnecessarily obscure
On Mon, Sep 09, 2002 at 07:20:14PM +0100, Andrew Suffield wrote: + The system administrator should be able to delete files in + `/usr/share/doc' without causing any programs to break. A package + should not directly reference files that it places there. Sure it should: ``further documentation may be found in /usr/share/doc/foo''. Better would probably be to say A package should not require the existance of any files in /usr/share/doc to run. Which is pretty much repeating yourself, if that matters. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: [RFC] *-rc.d - rc.d-* transition
On Sun, Sep 08, 2002 at 11:58:31AM -0700, Chris Waters wrote: The second reason is also about consistency: during the transition, there will be some packages using update-rc.d and some using rc.d-update, which may confuse people studying our packages. Not strong reasons, but reasons nonetheless. It also breaks partial upgrades once the transition is complete: upgrading sysvinit to an rc.d-update only version will mean you're no longer able to upgrade old packages to anything but rc.d-update compliant versions. If one of those packages happen to have become unmaintained in the meantime, you're a bit screwed. There's no way of avoiding this, since update-rc.d is considered essential and no one depends on it. You could do a tedious usr/share/doc-style transition over two or three releases, but there just isn't any point to all this. How pretty names are isn't *that* important. If they were, we'd've changed /etc to /conf and so on years ago. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpnIOcIYPTmV.pgp Description: PGP signature
Re: [RFC] *-rc.d - rc.d-* transition
On Fri, Sep 06, 2002 at 06:50:03PM -0300, Henrique de Moraes Holschuh wrote: As it was talked in Debconf2, we would be better off if we renamed all *-rc.d utilities (invoke-rc.d, policy-rc.d, update-rc.d) to rc.d-* (rc.d-invoke, rc.d-policy, rc.d-update). Uh, that seems entirely gratuitous. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgphy9BNwBVa2.pgp Description: PGP signature
Re: [RFC] *-rc.d - rc.d-* transition
On Sat, Sep 07, 2002 at 01:14:17PM +0200, Andreas Schuldei wrote: * Anthony Towns (aj@azure.humbug.org.au) [020907 13:11]: On Fri, Sep 06, 2002 at 06:50:03PM -0300, Henrique de Moraes Holschuh wrote: As it was talked in Debconf2, we would be better off if we renamed all *-rc.d utilities (invoke-rc.d, policy-rc.d, update-rc.d) to rc.d-* (rc.d-invoke, rc.d-policy, rc.d-update). Uh, that seems entirely gratuitous. I can not parse your comment. It's a waste of time, for no technical benefit. If we have to change the name anyway, then choosing a better name is worthwhile, but we don't need to change the name, so we shouldn't go around deprecating every single script that manages init.d scripts, and confusing all the developers and admins who've already taken the time to learn how update-rc.d works. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgp44asywSFKP.pgp Description: PGP signature
Re: Debian LSB Status
On Thu, Aug 29, 2002 at 06:57:38PM -0500, Chris Lawrence wrote: It had been my understanding that our init system and/or runlevels were an issue as well; is that a part of the spec we don't have to comply with for the specific certification we are seeking? [The] 1.2 spec [clarified] that the expected behavior of init scripts and runlevels called for in the specification only applied to LSB-conformant applications, and not to LSB-conformant implementations (i.e. distributions). There were actually a couple of other init-script related problems too. One was that the LSB allowed LSB packages to specify which runlevels they'd be run in, and gave meanings to those runlevels -- which, naturally enough, matched Red Hat's defaults and didn't match ours. This has been fixed to allow the install_initd binary to map them as appropriate. Our install_initd doesn't actually take advantage of this possibility at the moment, though. See: http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/runlevels.html Another was that the LSB claims control over the /etc/init.d/ namespace, and thus limits the scripts distributions can put in there without risking a conflict with some future LSB package. All the init.d scripts in woody/i386 are reserved for LSB compliant distributions, however, so this shouldn't be a problem. See http://www.lanana.org/lsbreg/init/init.txt Note that we should probably either make a practice of registering our script names with LANANA as we create them in future, or start using /etc/init.d/debian.org-foo. :-/ I'm not sure which of these would've been what was discussed at debconf, but they've all been adequately fixed, as far as I'm aware. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpIsK8ihjIaP.pgp Description: PGP signature
Bug#81852: Why do non-free programs with crypto have to be treated differently?
On Fri, Aug 30, 2002 at 09:20:25PM -0500, Manoj Srivastava wrote: Proposal is to change section 2.1.5 of the Debian policy to say: Non-free programs with cryptographic program code need to be stored on the non-us server because of export restrictions of the U.S. Umm. Is this right? Why are non-free programs being treated differently? Yup, it's right. They're treated differently because not all non-free crypto software can be exported from the US under the exemption we're using. It would probably be possible to handle some of it, but working differentiating between dfsg-free/non-free is hard enough, without adding a non-free-but-okay-for-crypto-export category too. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: Debian LSB Status
On Thu, Aug 15, 2002 at 07:37:10AM -0700, Grant Bowman wrote: What is (specifically) the current Debian perspective on LSB status? Debian 3.0r0 (woody), is close, but not quite, in compliance with LSB 1.2. The outstanding issues are: * alien's permissions and ownership handling (the woody version uses the cpio portion of the rpm exclusively, which is buggy; the version in unstable fixes the known problems) * pax has a minor POSIX violation wrt the major/minor numbers in non-device fields (also fixed in unstable) * our glibc has a number of POSIX compliance bugs; see Bug#156821 * kernel 2.4.18 has a number of POSIX compliance bugs, fixed in 2.4.19. There're 2.4.19 kernel-images in unstable, but the bf2.4 version used for boot-floppies hasn't been updated; see Bug#158026. * our glibc has the traditional Linux version of nice(), whose behaviour doesn't comply with POSIX. A waiver's been requested, see: http://www.opengroup.org:8000/lsb/publicpr/PRView?PR=0014 * the LSB runtime tests have buggy implementations of the msync and mprotect tests -- the former results in a false FAIL, the latter in a false FAIL or a hang, depending on your circumstances. Waivers have been granted for these, see: http://www.opengroup.org:8000/lsb/publicpr/PRView?PR=0009 http://www.opengroup.org:8000/lsb/publicpr/PRView?PR=0010 The alien, pax, and kernel changes should be fine for a point revision of woody, as should the glibc changes in Bug#156821, if accepted by the maintainers. The nice() changes probably aren't acceptable for a point revision (that's Joey's (Martin Schulze, stable release manager) opinion and mine, anyway), but it seems plausible that a waiver can be granted at least for the time being. In the meantime, you should be able to make your system LSB 1.2 compliant by: (a) running woody (b) adding deb http://people.debian.org/~ajt/lsb/ woody/lsb main to your sources.list, and installing libc6, and alien (c) running a 2.4.19 (or later) kernel (d) installing the lsb package and you should be able to demonstrate your system's complaince by: (e) installing pax (from the woody/lsb site) (f) installing tcsh (g) downloading the lsb-runtime-tests package from http://ftp.freestandards.org/pub/lsb/test_suites/released/binary/ (h) installing the test suite with `alien -ic lsb-runtime-tests-*.rpm' (i) setting up a password for the new vsx0 user, logging in as the vsx0 user (preferably at the console), and running ./run_tests (accepting the default options) (g) kill -9'ing the T.mprotect processes when they hang the test suite Note the tests take many hours to run, and that they create users and put include many setuid root binaries that are probably trivially exploitable, and it's probably a good idea to reformat and reinstall after running it. The testsuite isn't really meant for users to run over their own system. Finally, if you find an LSB package you want to install in general, running (h) alien -i lsb-blah-*.rpm on it. (The extra `-c' for the lsb-runtime-tests rpm is due to a bug in the runtime-tests: it's missing the required dependency on lsb) Anyway, once there's a decision on the nice() issue, we'll be aiming to get an official compliance statement done so as to obtain the available bragging rights. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpqNjGlRpipa.pgp Description: PGP signature
Re: Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Mon, Aug 19, 2002 at 01:14:31PM +0200, Josip Rodin wrote: On Sun, Aug 18, 2002 at 06:48:24PM -0500, Branden Robinson wrote: (BTW, someone's mailer is a complete piece of crap. What the F is up with mangling the subject line like that?) The BTS doesn't like the [ at the start of the Subject line, for some reason. It thinks space, : and [ all look alike, apparently, and drops it when getting rid of Bug123456:. Been that way forever, afaict, or at least since September '99. Might be fixed now. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: Rewriting policy soonish if poss.
On Wed, Jul 31, 2002 at 07:33:44AM -0600, Julian Gilbey wrote: On Wed, Jul 31, 2002 at 02:13:36AM +1000, Anthony Towns wrote: __Debian Standards Document__ dpkg: * version format * maintainer scripts are run when and under what circumstances Both of these are irrelevant to just about everybody, I'd've thought. Version number comparison is checked with 'dpkg --compare-versions', and the format is checked automatically by various tools. I've never found it necessary to look at the details of either except when I'm poking at apt or dpkg's internals, or when I've needed to do something really weird. * what control file fields mean Again, _what_ the fields mean (Essential: yes -- you can't uninstall a package easily, Depends: foo -- don't install this package unless foo's already installed) is a separate issue to when/why they should be used, and what effects their use has (Essential: yes -- installed on all Debian systems, so doesn't require a Depends unless it's new, in which case you need a versioned dependency, because of this rule, essential packages need to work unconfigured, etc). But with the wonders of XML includes, we can simply have the common pieces in appropriate separate external files (or something cleverer, but that's a detail) and include them in both places. I think you're getting a bit over excited about the wonders of XML... In this way, they will be both in the specs document (useful for specs!) and the guidelines (useful for package developers) and always be in sync - yeah! Including them in the guidelines just gets in the way. That's what I was saying about trying to write up the BPP and finding the version comparison, etc section being uncomfortable. If package developers need them, they should look in the specs. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgp271nWJsXk6.pgp Description: PGP signature
Re: Rewriting policy soonish if poss.
On Thu, Aug 01, 2002 at 12:06:55AM +0900, Oohara Yuuma wrote: On Thu, 1 Aug 2002 00:08:03 +1000, Anthony Towns aj@azure.humbug.org.au wrote: Version number comparison is checked with 'dpkg --compare-versions', and the format is checked automatically by various tools. I've never found it necessary to look at the details of either except when I'm poking at apt or dpkg's internals, or when I've needed to do something really weird. You say I should read the source of dpkg when I need to do something really weird about version number (cope with -pre and -beta, rebuild with dbs and so on)? Digits, dots and hyphens do not always work. No, I'm saying you should read the Specs Document. (Advice on coping with -pre and -beta and such should be in the Best Practices doc anyway though -- generalising from how the version comparison stuff works to a good way of handling pre-versions is non-trivial. Well, without ~, it is, anyway.) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: Rewriting policy soonish if poss.
internals will mean your programs don't work, so you should obviously care about the specs doc. And, really, who here *doesn't* want their packages to be the best they possibly can be? Forgetting whether all the above's good or bad momentarily, is it at least clear what I'm saying, and that for any given desirable bit of policy, there's some way of including it? Cheers, aj (Comparing the BPP/DSD dichotomy with the policy/packaging-manual split is left as an exercise to the reader...) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpbHYqjsMHNq.pgp Description: PGP signature
Re: Rewriting policy soonish if poss.
On Tue, Jul 30, 2002 at 11:44:38AM -0600, Julian Gilbey wrote: __Debian Standards Document__ dpkg: Most of the dpkg setup is so intricately connected with the packaging process, that separating out some of this seems somewhat weird. Although I guess that since this stuff is so clear and well-defined, it would be somewhat reasonable to simply cross-reference it. Well, the version format ([epoch]:[upstream]-[debian]), and particularly how version numbers are compared can be split out reasonably. The intricate details of how a .deb is made up, likewise. The archive's expectations of what a source package is (and what a .changes file is, for that matter), don't really affect the details of packaging much, either. The debian/rules interface might or mightn't be worth specing outside of policy, I don't know if anything but dpkg-buildpackage actually needs to care that much. I guess I'm mostly with you on this one now. Cool. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgp8bt5kNOwLl.pgp Description: PGP signature
Re: Rewriting policy soonish if poss.
On Thu, Jul 25, 2002 at 08:40:13AM -0600, Julian Gilbey wrote: I'd like to rewrite policy soonish. Into what, exactly? Last time this came up we had a nice flamewar about it, but didn't seem to resolve anything -- does it really make sense to do a rewrite while we as a project don't seem to have a clear idea of what policy's meant to be? Talking to Manoj the other day, I think it finally made sense to me what he was getting at, which leads me to think what we might be aiming at is to split policy into three separate docs: -- Release Critical Issues (a straight out list of problems that get a package pulled from testing, maintained by the RM) -- Debian Best Packaging Practices (guidelines on how to do packaging well, generally) -- The Debian Specifications Document (fairly formal specs on things like the version number format, format of .debs, layout of source packages, control file fields probably, update-rc.d spec, menu file format, and so on) Violations of the latter document can probably be checked completely automatically, and in many cases won't even make it into the archive. Many of the BPP guidelines will be able to be checked by lintian/linda too hopefully, at best only a few of them are worth RC bugs, though. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpouqAHJuxV4.pgp Description: PGP signature
Re: /usr/doc
On Sun, Jul 21, 2002 at 05:12:52PM -0400, Joey Hess wrote: If noone who is faimilar with the history and aims of this transition has any objects, the I will upload the new debhelper tomorrow, I guess. Sounds good. I suppose Santiago'll also be uploading a base-files without /usr/doc, if he hasn't already. Anyway, I'd thought we were considering removing all the symlinks in one shot rather than waiting for every package to be updated. Indeed, Manoj's message to the tech ctte said: ] We create the postinst, prerm now, installing the symlink, Once ] the move is over, we just have a prerm script removing the ] symlink. another release, (potato+2), we stop bothering, since we ] would have handled the most common case (and provide an base-files ] postinst script removing the symlinks for upgrades at that point). Of course, this script's lack of existance atm is no reason not to upload a new debhelper, etc. The only thing that could cause problems is packages that still use /usr/doc, which has been considered a RC bug for quite a while already, and hand written prerms that are broken and fail if their symlink isn't present. I don't think that's a showstopper, personally. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpJPLMS7GUdJ.pgp Description: PGP signature
Bug#151328: debian-policy: [PROPOSAL] virtual package debconf-2.0
On Fri, Jun 28, 2002 at 10:08:11PM -0400, Joey Hess wrote: Until these differences are identified, and resolved in the spec or at least implemented the same in debconf and cdebconf, it may be best if packages use debconf | debconf-protocol-2.0 in their dependencies so that dselect et al will pick the currently more sane choice by default. If debconf is standard or higher, and cdebconf is extra (or optional), debconf'll be chosen anyway (according to the old packaging manual [0]), so this shouldn't be necessary. Considering it'll also have already been installed everywhere anyway (by debootstrap, or by virtue of being the only debconf in previous releases), this doesn't seem like an issue at all. Seconded. Cheers, aj [0] wtf does debian-policy conflict: with the old packaging manual? It doesn't replace any files in it, and the packaging manual is still quite useful to have around considering it _still_ hasn't been properly replaced. Section 8.6, Defaults for satisfying dependencies - ordering is the relevant section in this case, in particular: Usually dselect will suggest to the user that they select the package with the most `fundamental' class (eg, it will prefer Base packages to Optional ones), or the one that they `most wanted' to select in some sense. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpGCIgzMskJL.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 01:53:58PM -0400, Joey Hess wrote: Take shoop benchmarks (this is an old shoop tree I had lying around): bash: 1000 shoop 1st-stage resolver method calls : 0:05.51 ash : 1000 shoop 1st-stage resolver method calls : 0:01.33 bash: 1000 shoop 2nd-stage resolver method calls : 0:08.33 ash : 1000 shoop 2nd-stage resolver method calls : 0:02.23 bash: 1000 shoop 2nd-stage(nocache) resolver method calls : 0:08.19 ash : 1000 shoop 2nd-stage(nocache) resolver method calls : 0:02.27 (On a TM5800 with the cpu set to run at 333 to 533 mhz.) Any chance of a rerun with posh (sources are in queue/new and readable) or pdksh? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 06:05:39PM -0400, Clint Adams wrote: 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.) I answered this explicitly already. It gives you a smaller, faster-loading shell and it supports brace expansions, which are the number one bug filed against #!/bin/sh scripts. As far as I can tell there are two possibilities here: (a) it is pdksh or posh, and it already works at least as well as ash on the various #!/bin/sh scripts in Debian, or (b) it is pdksh or posh or similar, and it doesn't yet work as well as ash on the various #!/bin/sh scripts in Debian, due to various POSIX extensions that we use and it doesn't support In (a)'s case, this means that we can just say Actually, as it turns out, we don't merely support ash and bash as /bin/sh at present, actually we lucked out and we already support ash, bash and pdksh! and have no more problems continuing to support pdksh as we're going to have continuing to support ash. If this is the case, then there's *still* no value in minimising /bin/sh: we can get the smaller-faster-loading-more-reliable-shell that you're talking about without having to fix all your various bugs. Whichever shell you're talking obviously already supports kill -9, type and command, and whatever other useful features that we currently use and you want us to stop using. If this is supposedly the case, it'd be helpful to know which shell this is, and if it does actually work as well as you're hypothesising. So, if someone needs to run a low-memory machine in production, [...] In (b)'s case, on the other hand, you _can't_ run whatever shell you're talking about on a production, because it _doesn't_ work as well as ash, and this entire line of argument's erroneous. Is this not an answer? Well, no, it really isn't. If some shell already works better with than some other supported shell in practice, then it's supported de facto -- continuing to support it doesn't require signficant changes to current practice, by definition. As such, it doesn't make sense to use that as an argument about why we should change current practice. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpgl01DfMsVr.pgp Description: PGP signature
Re: Bug#97671: RFD: Essential packages, /, and /usr
On Sat, Jun 22, 2002 at 02:02:00AM -0500, Manoj Srivastava wrote: Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden * Release critical bugs are _very_ rare.; and Branden * Release critical bugs should be the domain of the Release Manager, Branden Then we really don't need a tight connection between the Branden serious severity and release-criticality at all. Sorry, but this doesn't follow. Treating serious as a severity or a tag is largely immaterial, and the fundamental point of the serious severity or tag is as an aid to release management. Branden The Release Manager can strip the release-critical tag off Branden of any bug he wants. This is how things have *always* Branden worked in reality. No, it's not. In reality, things have always just been ignored, rather than being formally stripped of release-criticality. I find myself in strong and vehement agrement with Branden on this point. Branden brought up a number of interesting and good points (and, even better, simple) in the discussion he's referencing, but it was at the end of a pretty long winded and vicious argument about the referenced bug, and there was too much of an agree to anything just to get this over with on my behalf. Which isn't to say I don't agree with much of it, but I need some time to sit and look at this calmly before I can have a considered opinion on it. OTOH, there is one part that I have had plenty of opportunity to think about: and personally I don't believe debian-policy should have _any_ influence over the severity of a bug. If there're already good reasons for increasing the severity of a bug without policy, then that's good enough. If there aren't, policy shouldn't be forcing them on people. There're plenty of ways we can improve Debian without raising the members of the policy list as being better or more powerful than other developers. Beyond _all_ other things, this is the major problem with the serious severity and release-critical bugs (and debian-policy@) at the moment. And as much as I'd like to be able to say it's better to have -policy be better and more powerful than the release manager for general democratic and consensus principles, I'm sorry, but it simply hasn't worked, and I'm yet to see *anyone* even remotely interested in making it work. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpweSghV8iHS.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
that packages we install have useful documentation, or that they're sensibly configured out of the box, or that window manager menus are usefully setup to display all the interesting apps you have installed, or all the other nice things Debian does. Do you think I waited until after the alleged date of woody's release to file serious bugs because I was confused? Evidently. If you want to get them all fixed before the next release, file them early, and check up on their progress in a couple of months. The severity has *nothing* to do with that. I'm all too well aware that everyone thinks their pet fetish needs to be made a must in policy or it'll be utterly pointless to try to do anything about it at all, but, well, you're wrong. I'll try to be presumptuous about the meaning of policy now: | The standard shell interpreter `/bin/sh' can be a symbolic link to any | POSIX compatible shell, if `echo -n' does not generate a newline.[1] This means that /bin/sh should be almost POSIX-compatible. Yes. It's also wrong. If you want to argue about what is the case, I'll take the way the archive looks over policy's opinion any day. If you want to argue about what should be the case, I'll take arguments about practical utility and difficulty over policy's opinion any day. For the former, the echo -n exemption isn't nearly enough: we also need a fancier test, command -v, we don't support the funny \c characters in echo, and probably various other things. For the latter, you're yet to show *any* practical utility in using other shells -- and indeed you've demonstrated some reasons why you would *not* want to use other shsels, and you've already shown that we've got a fair way to go before we do support them. | Thus, shell scripts specifying `/bin/sh' as interpreter should only | use POSIX features. This isn't a must because such shell scripts must be allowed to use non-POSIX features, such as start-stop-daemon and what-have-you. Huh? Surely running scripts present on the filesystem is a POSIX feature? Violations of shoulds are normal bugs; if the above indicates what you seem to imply it does (ie, that calling start-stop-daemon breaks that guideline), then we ought to be filing bugs for every package that invokes start-stop-daemon from a script. | If a script requires non-POSIX features from | the shell interpreter, | the appropriate shell must be specified in the first line of the script | (e.g., `#!/bin/bash') and the package must depend on the package | providing the shell (unless the shell package is marked `Essential', | as in the case of `bash'). If this were not a must, then anyone could make a #!/bin/sh script that would not run on bash, and it would not be a valid bug. If it were a should, not a must, they would file a normal bug, and it'd get fixed. I'm not seeing the problem. Please make sure you've read section 1.1 of policy, particularly the paragraph beginning In this manual, the words _must_, _should_ and _may_, Perhaps you'd think it was a bug. Nevertheless, I can imagine one or two maintainers telling you that bash isn't a supported #!/bin/sh for this package. And I can imagine them getting a bug report from every user that runs their package. I can also imagine there being a fairly quick consensus on any list it was brought to that that was a stupid thing to do. Policy isn't a stick to beat people with, even when they make the most appalling idiocies. Stop pretending it is, or that -- if it isn't -- that we have no other possible recourse to ensure we produce a high quality system. If you can't justify a change without reference to policy, then you shouldn't be suggesting it, let alone demanding it. Policy's a convenient way to make sure you don't have to endlessly repeat yourself when filing bugs, or explaining to new maintainers how things should be packaged, but it's not a substitute for good sense. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpWrcEZ4GNE6.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
SUSv3 scripts will work on Debian (due to the echo -n issue, at least) Hrm. Is there anything more to this issue that actually affects anyone using Debian? I can't think of anything. So that just leaves: (4) Debian Policy underspecifies or misspecifies /bin/sh: it's not clear which POSIX extensions can be expected (eg, policy uses test's -a/-o/() parameters in some examples) (5) Clint wants to remove the -n exception for echo, which contradicts (rather than extends) POSIX. Do you really disagree with any of the above, in a way that you can actually manage to justify with something beyond handwaving? Can we possibly use this as a basis for establishing some sort of consensus on this issue? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpUWS2inaKak.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
sense if I spell it out as separate sentences? And really, none of the above have much to do with getting woody out at this point in time, either. and a bunch of other things. I can see obvious benefits from the latter, I can't see *any* benefits from being as obsessive as you're being with the former. Mind-boggling, that. Well, you're welcome to enlighten me at any time. Well, no, that's not really true. I don't mind having random scripts work on random other Unices, that's neat. And I wouldn't overly mind if you'd taken the time to do a little polite write up of why kill -9 isn't something we should do, post it to -devel along with citations people can easily check to the appropriate standards, and then file minor or wishlist bugs about it. Why do you think the bug severity levels are lies too? It violates a must directive. It also violates a should directive in the previous sentence, and considering the second sentence is just a restatement of the first, that means policy's buggy. The correct resolution, the one that leads to the better distribution, is the one that resolves both those directives to being should. Because, to be blunt, there are a million things that're a million times more important than whether you can use something other than bash as /bin/sh. No, it's the absolute most important thing in the two universes. Have you ever had need to put Debian on a small amount of flash, and wanted to be as space-efficient as possible? If you have only packages that use #!/bin/sh scripts, you can get rid of the Essential bash, and save over 400K. Sure, and you can do that with ash already, which is 82kB compared to 394kB for zsh. You can't do it incredibly reliably because scripts are allowed to randomly use bash wherever they want to. Hrm, how strange: lrwxrwxrwx1 root root 21 May 5 2001 /bin/zsh - /etc/alternatives/zsh* lrwxrwxrwx1 root root 12 Apr 4 15:26 /etc/alternatives/zsh - /usr/bin/zsh* lrwxrwxrwx1 root root9 Apr 4 15:20 /usr/bin/zsh - /bin/zsh4* The postinst seems right though, so I guess this is some bizarre upgrade bug. For some reason I've got /usr/bin/zsh listed as an alternative for /bin/sh in /etc/alternatives/zsh on that machine. Which is what policy is, if you ask me. This is also probably why you think violations of 'must' directives should get priority 'wishlist' bugs. No, I think that because policy is buggy. These bugs deserve wishlist/minor severity only -- that's their correct priority as far as Debian's users go. Things that don't work in ash deserve normal severity -- they're not *that* important, but at least people have some reason to care about that. Given that policy doesn't accurately depict that, well, there's a bug in policy. No, the professionalism and commitment to excellence of Debian maintainers is what ensures that. Well, since we can't get that, perhaps we should set some sort of policy. We can't get that? Since when? Are you refusing to be professional or offer a commitment to excellence? Maybe you should quit for the good of the project then. I haven't seen any evidence of either from you, but I'm happy to take you at your word. Perhaps you should look again at all the packages you've been filing bugs against. If you make /bin/sh something else, and lots of stuff breaks, that's evidence that you're missing a needed feature. A feature is needed just because someone uses it? Well, yes. If things stop working without a particular feature, they need it. The question is whether we want to change things so that feature isn't needed, and if so, how much we want to change that. That's nice. In future, before filing bugs against a bunch of packages for something you think's a policy violation, gain a consensus on -devel about it first. It's a simple rule, and it prevents a lot of annoyance. I think that you're the only one who has bothered to claim that it's not a policy violation to violate policy. *shrug* You're the only one who's gone on a bug filing rampage about it too. Since you're so scarily alone in that, clearly you're wrong. In any event, that guideline is there for exactly this reason: establish the consensus that you're right -- even if you don't see how anyone could possibly think otherwise -- *THEN* file the bugs. You'd think the people who insist on rules being followed to the letter would bother to read and follow them themselves, no? Manoj told me to file bugs; I didn't get the impression that he thought must was a typo. Sorry, Manoj is cool and all, but he's not a walking talking consensus all by himself. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpKNMWt5r7KJ.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 05:20:19AM -0400, Clint Adams wrote: I'm surprised by how many package scripts use kill, but the number is not excessive. On the other hand, no one seems to want to fix these. Imagine, people actually wanting a justification beyond random document X says so for bugs filed at a serious severity. Instead of a one-line fix, histrionics, bug-closings, and references to Solaris seem to be in order. See, this would be an example of using policy as a stick to beat people with. That some document somewhere -- be it POSIX, SUS, the LSB spec, or debian-policy -- says you should do something one way means *absolutely nothing*. The *only* reason to do things one way instead of another is because doing them that way is *more effective*. debian-policy is *only* useful in that almost all of its comments are time-tested instructions on how to do things in the most effective way. If you really want a document that says what features of the shell we rely on, that's fine: write one. Base it on SUS, or POSIX as necessary, but don't pretend POSIX or SUS is correct as it stands, least of all when you find evidence that *directly contradicts* such an assumption. Perhaps policy isn't a stick isn't the best way of phrasing these things, maybe a better way of phrasing it is policy isn't the law. Every time we find a contradiction between what we think is the right way of doing things and what policy, POSIX, or whatever says, policy should be put on trial just as much as any given developer. Surely we're all here looking for the *right* way to do things, not merely the documented way. Cheers, aj, getting sick of regretting anew the link between policy and release-criticalness everytime there's any sort of thread on -policy -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpf27aWzNWPw.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 07:59:33AM -0400, Clint Adams wrote: Imagine, people actually wanting a justification beyond random document X says so for bugs filed at a serious severity. How about I litter all my #!/bin/sh postinsts with useless zshisms? How about we add I'm not such an idiot to break my packages just because I get in an argument with aj? to the new-maintainer PP check? Scenario A: Anthony Towns puts kill -s KILL $pid in preinst of netkit-inetd. Script works on all POSIX-compliant shells. Scenario B: Anthony Towns puts kill -9 $pid in preinst of netkit-inetd. Script BREAKS on some POSIX-compliant shells. Scenario A: Script works on bash and ash, which are the two main shells anyone has a reason to use as /bin/sh on Debian. Scenario B: Script works on bash and ash, which are the two main shells anyone has a reason to use as /bin/sh on Debian. Why is one choice not obviously preferable to the other? Because you're biasses don't happen to be mine. It happens to be a lot of work to make something comply with the letter of POSIX's minimal specification for /bin/sh, especially since it seems to be intent on becoming more minimal as time passes, and since it doesn't seem to worry itself too much with existing BSD or Linux systems. It's also a lot of work to do heaps of other useful things in Debian: make it release faster, improve it's security, have all the neat new GUI apps get a similar degree of reliability as our server programs tend to have, and a bunch of other things. I can see obvious benefits from the latter, I can't see *any* benefits from being as obsessive as you're being with the former. Well, no, that's not really true. I don't mind having random scripts work on random other Unices, that's neat. And I wouldn't overly mind if you'd taken the time to do a little polite write up of why kill -9 isn't something we should do, post it to -devel along with citations people can easily check to the appropriate standards, and then file minor or wishlist bugs about it. Because, to be blunt, there are a million things that're a million times more important than whether you can use something other than bash as /bin/sh. debian-policy is *only* useful in that almost all of its comments are time-tested instructions on how to do things in the most effective way. No. That would be a best practices document. Which is what policy is, if you ask me. Policy is useful in that it ensures consistency and interoperability. No, the professionalism and commitment to excellence of Debian maintainers is what ensures that. If you really want a document that says what features of the shell we rely on, that's fine: write one. Base it on SUS, or POSIX as necessary, but don't pretend POSIX or SUS is correct as it stands, least of all when you find evidence that *directly contradicts* such an assumption. The only evidence I see that directly contradicts such an assumption is the dearth of shell features mandated. Perhaps you should look again at all the packages you've been filing bugs against. If you make /bin/sh something else, and lots of stuff breaks, that's evidence that you're missing a needed feature. You do realise we use policy as an aid to developing a distribution, not develop a distribution as an aid to writing policy, right? Perhaps policy isn't a stick isn't the best way of phrasing these things, maybe a better way of phrasing it is policy isn't the law. Every time we find a contradiction between what we think is the right way of doing things and what policy, POSIX, or whatever says, policy should be put on trial just as much as any given developer. Fine. That doesn't mean you should go around pretending that there's an exemption for 'kill -9' in Policy. That's nice. In future, before filing bugs against a bunch of packages for something you think's a policy violation, gain a consensus on -devel about it first. It's a simple rule, and it prevents a lot of annoyance. You'd think the people who insist on rules being followed to the letter would bother to read and follow them themselves, no? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpQoKxZNQ1aC.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 07:58:21AM -0400, Clint Adams wrote:
Notice or some other nice English word... when the admin puts binaries in
a $PATH, they need to be aware of the consequences. If they put something in
a place where it can replace a Debian binary, how do we know it's
Why would someone, being told that '/usr/local is for the administrator;
Debian doesn't touch it' assume that package scripts will go around
running things in /usr/local?
Just because they've been told Debian won't put things in there, that
doesn't mean the things in there won't be run if they're in the PATH.
I don't think anyone would be surprised or dismayed for particularly long
at having, say, /usr/local/bin/dpkg executed instead of /usr/bin/dpkg if
/usr/local/bin happens to be earlier in their PATH. If, as a sysadmin, you
don't ever want that to happen, you should remove /usr/local/{bin,sbin}
(and /opt/bin and whatever else) from your PATH before running
dpkg. That's not overly onerous.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
pgpBhpzaTtNCR.pgp
Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 03:56:12AM -0400, Clint Adams wrote: I would also support the addition of UP since all the POSIX shells in Debian support it with the exception of ash which does not currently support history. Since history support is unlikely to affect scripting, it would be acceptable for us to specify UP as well as XSI. I'd be happy with SUSv3, UP relevant to non-interactive use, and the appropriate subset of XSI. Of course, you realize that this reverses the 'echo -n' exception and that [...] ...you therefore have to say SUSv3, UP-noninteractive, XSI-something, and a BSD echo (ie, with a functioning -n). There're probably other exceptions too. Compatability with what we're distributing, compatability with other distributions, compatability with other free Unices are all more important than blind adherance to the standard du jour. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpDpz4GFr3Wh.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Sun, Jun 16, 2002 at 07:31:32PM +0200, Jochen Voss wrote: On Sun, Jun 16, 2002 at 11:53:50PM +1000, Anthony Towns wrote: On Sun, Jun 16, 2002 at 01:48:21AM -0500, Branden Robinson wrote: Documentation good. Ad hockery bad. That's your opinion, not mine, and not the word of God that you make it out to be. Sorry Anthony, but are you really telling us that in your opinion not documenting technical things should be prefered to documenting them? Ad hockery can often be quite productive and helpful and useful, all of which are good, not bad. I'd cite Linux as a whole as an example. Documentation can often be a nuisance: if there's too much of it or if it's badly written so it's hard to find anything, or if it doesn't match reality, or if the burden of maintaining the documentation stops you from doing things that would be productive. Things are very rarely as simple as four legs good, two legs bad. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgp74MbRgXNq8.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Sun, Jun 16, 2002 at 03:13:23PM -0500, Branden Robinson wrote: Aj, on the other hand, is logically asking for continuing to use package priority I thought he was asking that we use package essentiality, though I suppose one could argue that essential is a virtual priority, one higher than any others. Alternatively, my grep-available command needs to be changed. If you need to use a binary that's not in an Essential: yes package, but is in /bin, you can Depend: upon that package, then use it. /sbin/ifconfig from net-tools, or /bin/ip from iproute for example. The required priority is meant to be essential + dependencies, but isn't quite, for reference. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpFv3tGqEkF3.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Mon, Jun 17, 2002 at 10:32:03AM -0500, Steve Greenland wrote: 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. 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. 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. Are you sloppy when you exercise your judgement about your packages? Why would you expect everyone else to be? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpPafxa3cfD1.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
On Thu, Jun 13, 2002 at 01:17:45PM -0500, Branden Robinson wrote: So why waste everyone's time discussing it rather than just using sed or /bin/sh and getting on with your life? Because this isn't just about me, and it isn't just about cut(1).[1] cut was what was brought up. Do you really care about ddate being in /bin rather than /usr/bin? It's about what authors of early-running init scripts in general can expect to have at their disposal. They can expect to have what they absolutely need, and pretty much nothing else. If there's something cut can do that sed can't that's absolutely needed by an init script that needs to run before /usr's mounted it'd be reasonable to move it. If it's just a nuisance to have to learn a different tool, well, that's not a reason to move cut. The set of files provided by Debian's Essential packages is, in fact, minimal. Depends what you mean. Yup. So what *does* Debian mean? ddate, dpkg, dselect, factor, find, mawk, perl, sort, tr, tsort, uniq, update-rc.d, whoami, xargs, and yes are all in essential packages and in /usr/bin. As are logger, [...] The items listed above are ones that generally need to be in essential packages. Particularly perl, sort, tr and kin. That is to say, they need to be available for the Debian packaging tools to function. Are all of the above necessary for minimal operations? Certainly not. But they don't need to be available to mount /usr. Whether they're needed for minimal operations depends on which of those options you're referring to. Should every single one of these be off-limits to early-running init scripts and people attempting to recover their systems? I don't think so. If they're not in /usr, they're off-limits. And the burden of proof lies on you to demonstrate why you absolutely must have any particular one available beforehand. Given that test and which are extremely useful for figuring out what's on the system for control flow purposes, If you're running before /usr's mounted, you're using stuff from /bin or /sbin, so there's not a huge amount of benefit to being able to figure out where you're running from. Further, /bin/bash is available and provides both type and test as builtins. Essential packages are the ones needed to maintain a Debian system; utilities in /bin and /sbin are ones needed to recover a system. Okay, great. Where's our official list of utilities needed to recover a system. OH NO! THERE'S _NO OFFICIAL LIST_!!! THEREFORE EVERYTHING I SAY MUST BE WRONG OH WOE IS ME!! What can early-running init scripts, not to mention sysadmins ACTUALLY TRYING TO RECOVER A SYSTEM, rely upon to be present? Depends how badly your system's screwed. In some cases you can't rely on anything working (libc6 is screwed, sash isn't installed, the kernel got corrupted, you have a hardware failure...). Are you suggesting that we substitute your judgement of what is minimal for the Debian Policy Manual's? People like Herbert's judgement is what was used to write the policy manual. I hate to break it to you, but I'm the author of several accepted policy proposals as well. Then maybe you should consider actually having a discussion about it, rather than, say, appealing to scripture at every chance you can (the Debian Policy Manual's [judgement] or Where's the official list of utilities needed to recover a system[?]) or dismissing reasonable objections out of hand (I invite your participation if you have something to contribute beyond don't do that, then.). I'm CCing debian-policy as a means of RFD. I invite your participation if you have something to contribute beyond don't do that, then. Sometimes so don't do that, then is the right answer. See above. All I hear from you are arguments for the status quo, [...] Sometimes the status quo happens to be quite a good compromise of all the various interests at stake. Given the tone of your reply, Anthony, that means you. Ah, yes, clearly your lack of satisfaction with things means others should be proactive in providing for your happiness. If you have a problem with some particular program being in /bin instead of /usr/bin or vice-versa, discuss it with the maintainer and provide a convincing argument why it shouldn't be where it is. Or don't, run off to mummy, or -policy or the tech-ctte and whine about how no one ever plays fair with you like you usually seem to. Whatever. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Sun, Jun 16, 2002 at 01:48:21AM -0500, Branden Robinson wrote: On Sun, Jun 16, 2002 at 03:16:12PM +1000, Anthony Towns wrote: On Thu, Jun 13, 2002 at 01:17:45PM -0500, Branden Robinson wrote: So why waste everyone's time discussing it rather than just using sed or /bin/sh and getting on with your life? Because this isn't just about me, and it isn't just about cut(1).[1] cut was what was brought up. Do you really care about ddate being in /bin rather than /usr/bin? No. Is it your position that every executable from an Essential package that isn't already in /sbin or /sbin is as frivolous as ddate? If not, why imply it? I'm sorry if you're unable to understand my inferences. That particular one was that not all programs in essential packages need to be in /bin. One of dpkg, update-rc.d or ddate ought to be enough of an example to demonstrate that without going off on too much of a pointless tangent. If you don't want to claim that all programs in essential packages need to be in /bin or /sbin, then you've established two things: * that minimal means different things when talking about the contents of /bin and /sbin compared to the contents of essential packages * that programs that do go in /bin or /sbin need stronger recommendations than just they're important enough to be in an essential package. It's about what authors of early-running init scripts in general can expect to have at their disposal. They can expect to have what they absolutely need, and pretty much nothing else. So, rather than establishing any guidelines for what they're going to absolutely need, we'll just tell them that what they absolutely need is whatever happens to be in /bin or /sbin today. No, we'll tell them to use their common sense. You don't absolutely need cut, since you can use sed instead. If there's something cut can do that sed can't that's absolutely needed by an init script that needs to run before /usr's mounted it'd be reasonable to move it. If it's just a nuisance to have to learn a different tool, well, that's not a reason to move cut. s/cut/$anything/ If you're going to try to generalise a concrete example at least do it right: s/cut/some tool proposed to be added to /bin/g s/sed/any tool already in /bin or /sbin/g s/an init script/a program/g And if the package maintainer disagrees? Which package maintainer? The set of files provided by Debian's Essential packages is, in fact, minimal. Depends what you mean. Yup. So what *does* Debian mean? Interesting that you didn't bother to propose an answer to this. Interesting that you *still* haven't noticed that it's an ambiguous question, that *can't* be answered (correctly) until you clarify what you mean. The items listed above are ones that generally need to be in essential packages. Particularly perl, sort, tr and kin. That is to say, they need to be available for the Debian packaging tools to function. That's the definition of an Essential package, not the definition of a minimal Debian system. A minimal Debian system is one that has all the essential packages installed with their dependencies satisfied (so libc6 and mawk and such as well). This has nothing to do with the contents of /bin or /sbin. It has to do with the fact that the word minimal is used in different contexts. Do you realise that sash.deb provides /bin/sash and is priority: optional? If they're not in /usr, they're off-limits. As are the POSIX utilities for determining whether or not they're in /usr. *shrug* POSIX has absolutely no relevance here. And the burden of proof lies on you to demonstrate why you absolutely must have any particular one available beforehand. Translation: the intersection of all Essential package maintainers' opinions shall determine what will be possible before /usr is mounted. Well, no. The original was in English, so you don't need to translate it at all. If you want something added to /bin or /sbin that's currently under /usr, *YOU* have to provide a convincing argument as to why it needs to be moved. As opposed to complain about how there's no convincing argument as to why it's where it is. Further, /bin/bash is available and provides both type and test as builtins. Bad news for any Debian port that wants to use ash as its Essential shell, then. Well, yes. bash is Essential: yes, and may be assumed to be present on all Debian systems. If some port wants to change that assumption they get to clean up the mess. OH NO! THERE'S _NO OFFICIAL LIST_!!! THEREFORE EVERYTHING I SAY MUST BE WRONG OH WOE IS ME!! We have neither a list nor a set of guidelines documented anywhere as to what the maintainer of an early-running init script can expect to accomplish. Instead, he has to experiment, [...] Or he could ask on -mentors or -devel if he can't figure out how to use the tools in /bin
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 11, 2002 at 12:35:27PM -0500, Branden Robinson wrote: On Fri, Jun 07, 2002 at 02:55:23PM +1000, Herbert Xu wrote: Anyway, there are already plenty of tools in /bin capable of performing the task of cut(1). Sure. So why waste everyone's time discussing it rather than just using sed or /bin/sh and getting on with your life? The set of files provided by Debian's Essential packages is, in fact, minimal. Depends what you mean. ddate, dpkg, dselect, factor, find, mawk, perl, sort, tr, tsort, uniq, update-rc.d, whoami, xargs, and yes are all in essential packages and in /usr/bin. Essential packages are the ones needed to maintain a Debian system; utilities in /bin and /sbin are ones needed to recover a system. Are you suggesting that we substitute your judgement of what is minimal for the Debian Policy Manual's? People like Herbert's judgement is what was used to write the policy manual. I'm CCing debian-policy as a means of RFD. I invite your participation if you have something to contribute beyond don't do that, then. Sometimes so don't do that, then is the right answer. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpdFKDPybJX0.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
On Mon, May 13, 2002 at 01:29:59AM -0500, Manoj Srivastava wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony The documentation should be found wherever the dpkg Anthony maintainers want it, not wherever the -policy maintainers Anthony think might be fun. What policy contains won't be documentation. It shall be a standard interface that must be implemented by any Debian packaging tool -- and be the only policy requirement from Debian packages and packaging tools. Since dpkg folk have already stated their commitment to not changing interfaces out from under all the packages, this ought not to be any inconvenience to them. Having a standard interface would enable us to, *gasp*, allow the implementation of another packaging tool. Julian, please note the above: this is who's talking about dpkg anyway. There is _absolutely_ no call for other packaging tools, and absolutely _no_ need for a standard to make this easy or possible. Further, writing such standards _without_ implementing two or more interoperable tools is poor practice and generally results in useless standards. Reforming policy into a pointless standards document, while gutting all the useful best practices information into an as-yet hypothetical new document seems a lot like a pointless exercise in bureacracy. As one of the agitators for a policy team rather than a policy dictator, one might've hoped that at the very least you might at least try to reach a consensus, rather than dictating from on high about what policy will and won't be. A simple question: who, today, will be helped by having a document called debian policy that documents the interfaces to dpkg? How will this be more helpful than the existing dpkg manpages, or other alternatives. Likewise, who is being helped, today, by the documentation about best practices in policy? BTW, I don't think I ever got a firm answer on which bits of policy describe best practices rather than standards, and are thus unsuitable. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgp6ZxFcz2t5d.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
On Mon, May 13, 2002 at 01:45:33AM -0500, Manoj Srivastava wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: *Sigh*. Let me see if I can dot the i's and cross the t's. A package should be buildable using the bits mentioned in policy. Any package may, however, choose to add any extra bits added by dpkg, (perhaps buigld depending on a new dpjg version if the change is not compatible with older versions). Anthony This, uh, doesn't make sense. Really? Yes, really. Anthony A package should be buildable using nothing more than Anthony [foo]. Unless it chooses not to be. Anthony ...seems to be what you just said. Umm. I fail to see how else I can define sufficient, and optional, new, added features. Policy defines the minimal, sufficient interface. Sufficient for what? Certainly not sufficient to build all Debian packages, since they can use the optional, new, added features that aren't included. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpsy1TxSeaaY.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
On Mon, May 13, 2002 at 10:42:02AM -0500, Manoj Srivastava wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony There is _absolutely_ no call for other packaging tools, and Anthony absolutely _no_ need for a standard to make this easy or Yeah, right. There is never any need for competition or diversification, or any standards that may acknowledge the difference between an interface and documentation of a specific implementation. No. There is plenty of need for some standardisation. There is no need for *this* standardisation. Anthony . Reforming policy into a pointless standards Anthony document, while gutting all the useful best practices Anthony information into an as-yet hypothetical new document seems a Anthony lot like a pointless exercise in bureacracy. Whatever. I see you have no interest in meaningful dialog (pointless standard), If you're interested in meaningful dialogue, I'd invite you to answer the question you cut from my previous mail: ] A simple question: who, today, will be helped by having a document ] called debian policy that documents the interfaces to dpkg? Perhaps I should've written standardises instead of documents. The meaning of the question, to try to avoid pedantic squabbles, is please name the people who'll benefit from these changes. If you can't name anyone, I'd contend quite strongly that you've got no way of judging if the changes are successful or not, and thus a good chance of doing them poorly. Further, since no one needs them, doing them is a waste of time and energy. I'll refrain from pointing out that policy has always defined the format of version numbers, Control files, changelogs, and other details of how a package interfaces with the packaging system. Chapters 3, 4, 5, 6, 7, and 8 of the curtrent policy already define the interface. I'm so glad you refrained from doing that. Anthony As one of the agitators for a policy team rather than a Anthony policy dictator, one might've hoped that at the very least Anthony you might at least try to reach a consensus, rather than Anthony dictating from on high about what policy will and won't be. Had I been a dictator (unlike the RM), we would never have been having this pointlessly futile discussion. If you were seeking consensus, rather than having already decided, this wouldn't be a pointless or futile discussion. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpoW4AhYgcRR.pgp Description: PGP signature
Re: The Serious severity
On Mon, May 06, 2002 at 07:17:12PM +0200, Marcus Brinkmann wrote: On Tue, May 07, 2002 at 12:12:16AM +1000, Anthony Towns wrote: On Sat, May 04, 2002 at 10:08:51AM -0400, Marcus Brinkmann wrote: I don't care about now, I care about the next release, or the release after that. Then how about you spend a moment thinking about it from _my_ perspective and stop whining until the next release or the release after that. Yeesh. If I wait until the next release happens, How about you wait 'til _this_ release happens, then? Debian development is asynchronous. That's a nice idea in theory. Cheers, a bottleneck j -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: init.d scripts and LSB
On Tue, May 07, 2002 at 01:57:51PM +0200, Marcus Brinkmann wrote: No, the purpose of the LSB is to provide a standard ABI and API for applications to link and program against, whether or not the underlying system has the Linux kernel or not. It has a strange name for that purpose. Is it just a misnomer? Refer back to the /usr thread on another list... Is the purpose only to run applications that are within the scope of what the LSB defines? What about programs like CD burner software, audio applications and other programs that use kernel-specific ioctls? Are the ioctl interfaces defined in the LSB? The LSB's very incomplete. The latest version still specifies things that make it impossible for Debian GNU/Linux to meet the standard, let alone FreeBSD, Solaris or the Hurd. The next version will be somewhat better, and later versions will hopefully continue the trend. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#146023: suggested patch against policy, documenting libexec, or current custom on use of lib for binaries in lib* packages
On Mon, May 06, 2002 at 05:41:20PM -0500, Manoj Srivastava wrote: Junichi == Junichi Uekawa [EMAIL PROTECTED] writes: Junichi I think this was discussed enough in -devel already, but Junichi some good points about /libexec was given. I've noticed Junichi that some known good practice is not documented in policy, Firstly, there is no such consensus that I can see. Secondly, I have not seen any technical reason to make Packages change. Did you look at the patch, or just read the introduction? Junichi just seems to be codifying current practice (If you want to include support stuff in a lib* package, put it in /usr/lib/pkgname so when you install libfoo2, you don't get file conflicts), not introducing random new stuff (Put stuff in /libexec! Yay hurd! Yay BSD! Boo FHS!). Are there any packages that don't comply with the patch, that don't already have problems with the fourth paragraph of section 11.3? Junichi and I propose the following patch: This is way premature. Patches are almost always a good thing, even if they're completely unsuitable to be applied. This one doesn't seem particularly unsuitable. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpX4Y1MWeRep.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
On Mon, May 06, 2002 at 06:11:46PM +0100, Julian Gilbey wrote: On Fri, May 03, 2002 at 08:02:50PM +1000, Anthony Towns wrote: I'm concerned about this because when I tried passing over release-critical policy issues to the policy group, it didn't work. [..] Strawman (to quote lots of others). As a concept, it's very good, but as we discovered, the implementation was poor. As a concept it sucked, we just didn't realise it at the time. -policy isn't competent at judging which issues should be release critical. We didn't realise this before we tried, no we have tried and it's blatanly obvious. I'd suspect the reason it doesn't work is because there's no downside for -policy to making a rule a release-critical issue, compared to not doing it. You guys don't have to try to coerce people into fixing their RC bugs in a timely manner, nor throw out packages that don't have their RC bugs fixed, nor deal with the people who absolutely need the package. The only downside has been that if you try adding a release critical requirement, I'll jump down your throats. And that doesn't have any wins over me just deciding which issues are RC and which aren't. 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. There'll be a separate document, maintained by the release manager. It may or may not be included in debian-policy.deb. I'm inclined to think it'd be better if it were in that package, but we'll see. Further, considering that everyone seems to think that the -policy group have done pretty poorly at their actual job -- maintaining the policy document so that it's readable, consistent and useful -- it doesn't seem like a good idea to broaden its scope. Rewriting it into something comprehensible, making the already approved of changes, and merging all the subpolicies (at least debconf, perl, and python) is likely to be more than enough work for the forseeable future. Thanks. Appreciated. We need to rewrite policy, and have known this for absolutely ages, but when it absorbed the old packaging manual, it introduced the contradictions (oops). I vaguely recall that at that time, a freeze was effectively placed on substantially rewriting policy because of the upcoming freeze of woody. This was about six months ago, and you and Manoj were too busy to do anything at all about it (and there aren't any other active policy editors to do it). The packaging manual was included about four months earlier than that. It doesn't really matter. Doing a good rewrite of what's currently in there, incorporating all the separate mini-policies that're about, and adding all the new policies that need to be added will be a lot of work, even without trying to make a dpkg standard. We are still in this freeze period, and both Manoj and I are itching to rewrite the current spaghetti which is called policy. So start. Rewriting means no changes to the substance anyway (or so I'd assume), which means there aren't any problems at all with it as far as I'm concerned (with my release manager hat on). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- 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 Mon, May 06, 2002 at 06:19:54PM +0100, Julian Gilbey wrote: Then each section could either have the structure: Policy dictate s Discussion, useful information, guidelines, examples or we could merge them, and have policy dictates all in the form MUST, SHOULD, MAY, MUST NOT, etc., as in the RFCs. I'm quite confident that trying to differentiate between requirements and guidelines like this will turn out to be completely unhelpful and a large waste of time, personally. Don't RFCs do this frequently? And I've never heard people making such a complaint about them. RFCs have a different goal to -policy. RFCs specify things that get implemented by different groups and have to be interoperable. -policy doesn't. There is only one dpkg, there is only one apt, there is only one Debian, and the point of -policy is to make all of these more effective, not to help random people with nothing better to do implement clones. If we were doing the latter (and you and Manoj seem to want to wrt dpkg for no reason I can fathom), then must/should would be useful. But we're not. If people want to clone dpkg (or finish of libapt-inst so it can actually install packages; or implement Herring (if anyone even *remembers* it...)) then more power to them. If someone does do this, then it might turn out that there are some incompatibilities that need to be handled specially by packages, and we'll probably add these to policy when we find them. Maybe, some day, there'll be a handful of competing dpkgs and we will need a standards document to say what constitutes a valid dpkg, but that ain't today. So why waste time on it? (As far as RC issues goes, this could be marked by (RC) after the MUST/SHOULD/whatever, with a catchall at the start of policy that the final decision on what is RC rests with the release manager.) As far as RC issues go, they'll be specified in an entirely separate document, not maintained by the policy group. Do you really expect bug submitters to consult yet another document, or is it just so that you can point people to it and say See, this is not considered an RC bug!? Bug submitters already look at another document. That document will merely change from being the entirety of policy, to something a fair bit shorter and a fair bit more on-point. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpPKnPlErWu0.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
On Mon, May 06, 2002 at 06:11:46PM +0100, Julian Gilbey wrote: On Fri, May 03, 2002 at 08:02:50PM +1000, Anthony Towns wrote: If the dpkg authors would like to hand off some of their design decisions to -policy on a generalised basis, I'm sure they'd say so. It seems a bit, well, wrong-headed for -policy to be trying to take control of dpkg though. Quite: IMHO discussion is about where the documentation should be found, not about the maintenance or control of dpkg! [...] The documentation should be found wherever the dpkg maintainers want it, not wherever the -policy maintainers think might be fun. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgppwpCLf7rcw.pgp Description: PGP signature
Re: The Serious severity
On Thu, May 09, 2002 at 08:02:04PM +0200, Wichert Akkerman wrote: Previously Anthony Towns wrote: On Mon, May 06, 2002 at 07:17:12PM +0200, Marcus Brinkmann wrote: Debian development is asynchronous. That's a nice idea in theory. It just to be true before we had testing. I can assure you I had a lot less time to do stuff like fiddle with the BTS when I was trying to get potato released. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgp7rP9xFz705.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
On Mon, May 06, 2002 at 05:19:09PM -0500, Manoj Srivastava wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony The real question is whether maintainers are meant to build Anthony using the features of dpkg, or the ones listed in *Sigh*. Let me see if I can dot the i's and cross the t's. A package should be buildable using the bits mentioned in policy. Any package may, however, choose to add any extra bits added by dpkg, (perhaps buigld depending on a new dpjg version if the change is not compatible with older versions). This, uh, doesn't make sense. A package should be buildable using nothing more than [foo]. Unless it chooses not to be. ...seems to be what you just said. If you want to say something like Packages should specify a versioned build-dependency if they use features from a package that weren't available in both the last two stable releases, that's fine by me --- but you don't have to write out a dpkg spec to say that. (If you want to make sure it works, you could set up a buildd with a two year old chroot, or similar, and file bug reports with patches when you find problems) Speccing out dpkg is not what policy is for, and doesn't win us anything. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpk2pz1Mzxxs.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
-project Bcc'ed only. On Thu, May 09, 2002 at 11:17:28PM +0100, Julian Gilbey wrote: On Fri, May 10, 2002 at 04:02:47AM +1000, Anthony Towns wrote: On Mon, May 06, 2002 at 06:19:54PM +0100, Julian Gilbey wrote: Then each section could either have the structure: or we could merge them, and have policy dictates all in the form MUST, SHOULD, MAY, MUST NOT, etc., as in the RFCs. I'm quite confident that trying to differentiate between requirements and guidelines like this will turn out to be completely unhelpful and a large waste of time, personally. Don't RFCs do this frequently? And I've never heard people making such a complaint about them. RFCs have a different goal to -policy. RFCs specify things that get implemented by different groups and have to be interoperable. -policy doesn't. There is only one dpkg, [...] Who's talking about dpkg here? Manoj, for one: ] [...] The policy group shall never propose additions to ] dpkg functionality, the way the section shalll be formulated. What ] shall be in the section is what the maintainers _must_ have in order ] for their packages to be built. This is the core interface that dpkg ] already presents [...] Policy covers far more than that. Actually it covers different things than that, which is my whole point. The RFC-style M/S/M remarks are just tangential. For example, when talking about shared and static libraries, there may be exceptional cases where both the shared library and the development parts (headers and static library) live in the same package. Then one would say something like Source packages providing shared libraries SHOULD produce a binary package containing the shared library and another binary package containing the development files (headers and statically compiled library). The shared library MUST be compiled with the -fPIC option and the static library MUST NOT be compiled with this option. ... (Please don't correct me on details here -- I haven't checked them up and that's not the point.) Which is to say that if I demonstrate that your MUST or MUST NOT could happen to have exceptions, that you're not going to listen, and thus I've got no way of usefully demonstrating my point, which is that almost every MUST you might choose will have some sort of exception, and thus should be a SHOULD. In the above, for example, the xlibs-pic package provides static libraries that are compiled with -fPIC, making your MUST NOT inappropriate. So here, the SHOULD means that it must behave in this way unless there are exceptional circumstances, and the MUST means that there are no exceptions. I may be wrong in the details of this specific case, but this is the way I am thinking. I completely understand the distinction you're trying to make, I just think you'll find that there aren't many situations where MUST is appropriate, and that there aren't any where it's particularly useful. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpgaQaTQneov.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
On Sat, May 04, 2002 at 09:02:24PM -0500, Manoj Srivastava wrote: Adam == Adam Heath [EMAIL PROTECTED] writes: Adam We(Wichert and I) implement features that users want, when we Adam have time. We implement those that are interesting to us when Adam we have free time. I don't think either one of us would feel Adam comfortable being led by another group. Strawman. The policy group shall never propose additions to dpkg functionality, the way the section shalll be formulated. What shall be in the section is what the maintainers _must_ have in order for their packages to be built. That statement's a bit ambiguous. The real question is whether maintainers are meant to build using the features of dpkg, or the ones listed in debian-policy. The former makes sense and works; the latter means that any new features in dpkg have to go through the hurdle of debian-policy for no good reason. We already expect dpkg not to break existing packages, we already are happy to ignore features in dpkg that are useless, we've no need to support different implementations of dpkg (anyone remember Herring?) -- and if we did, they'd have to support the undocumented-in-policy features that some packages will be using anyway -- and we already have a few people who need to be convinced of any major changes (apt needs to grok Packages files as well as dpkg, apt-ftparchive needs to be able to grok .debs and source packages), and we already have plenty of areas to discuss any changes if discussion is needed. Having that in policy serves two purposes -- it is a quick, minimal reference to the standard interface to packaging tools for debian developers, Policy is not a HOWTO, and doesn't work as a HOWTO. If you want a quick minimal dpkg reference, use the packaging manual or the man pages, or write a HOWTO. and it shall be the common basis that any other packaging tool apart from dpkg must implement in order to qualify. Like I've already said -- standardisation for standardisation's sake. From time to time, the dpkg authors could ask for additional functions to be added to the core set, at your discretion, when you think it has become a part of the standard interface debian packages have to the packaging system(s). If stuff's added to policy after it's been tried in various packages, then it doesn't document enough for reimplementations of dpkg, if it's added before, it'll have to document things before they've been tried and demonstrated to be useful. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Serious severity
On Sat, May 04, 2002 at 10:08:51AM -0400, Marcus Brinkmann wrote: I don't care about now, I care about the next release, or the release after that. Then how about you spend a moment thinking about it from _my_ perspective and stop whining until the next release or the release after that. Yeesh. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpgzrtYVrGAd.pgp Description: PGP signature
Re: The Serious severity
On Fri, May 03, 2002 at 05:27:30PM +0200, Marcus Brinkmann wrote: On Fri, May 03, 2002 at 08:16:32PM +1000, Anthony Towns wrote: On Thu, May 02, 2002 at 07:15:09PM -0400, Joey Hess wrote: Seems to me that if bug severity is orthagonal to release criticality People keep saying that, but it's not true [0]. Release critical bugs are those that are serious, grave or critical. Either this is not true, or the BTS documentation is wrong. [[hurd isn't treated the same as i386]] There are many unwritten rules about how bugs need to be treated, and they change depending on what seems the best way to get a working release out. In particular, filing hurd bugs at high severities before release (especially when people are already uploading relatively untested packages with high urgencies) seems likely to lower the quality of woody dramatically. Adding arch tags aren't possible in the short term, and it's not particularly clear that they'd be helpful at solving that particular problem. You're quite welcome to hax0r the BTS slightly to make it easier to track hurd bugs. You can, eg, add your own pseudo-header to say X-This-Is-RC-For-Hurd: yes and then grep through the bug spool later to find them all again and upgrade them when you are actually near release. Or have a special submitter address (debian-hurd@lists.debian.org) and use http://bugs.debian.org/from:debian-hurd@lists.debian.org to look over them. Helping hurd release sometime in the next few years isn't important enough to risk breaking Linux/i386 now. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgp4mEkq8ZEHW.pgp Description: PGP signature
Re: The Serious severity
On Sat, May 04, 2002 at 10:16:09AM +0200, Marcus Brinkmann wrote: And, why should the severity only be useful for the release manager, and released architectures? Think about it for a while from any perspective but a hurd hacker's for heavens sake. Think about what should get the highest priority right now, a hurd release in a few years or an i386 release in a few weeks. Think about the usual effects of uploads to fix hurd specific bugs (which is to say: breakage everywhere else). Think about how much time I can possibly devote to your whims about the BTS considering the various other things I can devote my time too. Think about whether anyone else at all can or will do anything about them. Think about the sort of ratio of effort that's reasonable to put into doing things versus justifying why they're done this way. Think about whether there's any real practical benefit to insisting on someone else doing things the way you want, rather than you just hacking around the problem yourself and getting stuff done. _Think about things_ godammit. Cheers, aj, who wishes he'd remember that he'd given up on transparency already -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- 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
Is there any reason for this thread to still be on -project? It's entirely about rewriting debian-policy now, isn't it? On Thu, May 02, 2002 at 03:32:11PM +0200, Wichert Akkerman wrote: So if the dpkg reference doesn't document everything that Debian needs in this respect, what is the best thing to do? dpkg allows things that Debian does not. Version numbering for NMUs is a good example of a policy that Debian adds on top of what dpkg provides. The use of the Essential: keyword is similar (as far as dpkg is concerned, that keyword just makes it harder to --remove stuff; as far as policy is concerned it allows you to refrain from listing things in Depends:), as is the use of Priority: and Section:. There will be a reference manual for dpkg that documents only dpkg specifics. You are free to copy parts of that into Debian policy, but I would rather have them as seperate documents. That means people will need to read both, but that might give them a better understanding of how Debian is build. ObShot: Much like, say, people used to have to read both the packaging manual and policy... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpw4sycuuSy4.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
On Thu, May 02, 2002 at 03:20:45PM -0500, Manoj Srivastava wrote: Julian == Julian Gilbey [EMAIL PROTECTED] writes: Julian Surely either everything necessary should be in the dpkg reference or Julian everything necessary should be in policy. q On the other hand, all packages must not be left to the whimsy of the dpkg developers either; This is rather non-sensical: all packages /are/ left to the whimsy of the dpkg developers. If you don't believe me, I'm sure Wichert or Adam will be happy to introduce some random bugs in dpkg 1.10.x to demonstrate. If the dpkg authors would like to hand off some of their design decisions to -policy on a generalised basis, I'm sure they'd say so. It seems a bit, well, wrong-headed for -policy to be trying to take control of dpkg though. since potentially large numbers of packages would be impacted by such changes. The dpkg maintainers are well aware of the likely impact of their changes, and are quite able to ask for advice when it's needed. I'm concerned about this because when I tried passing over release-critical policy issues to the policy group, it didn't work. Not only did everyone regularly and frequently lose track of what the point of must versus should was, but people just weren't very good at knowing when to choose which. Which is fine: we tried an experiment, it didn't work out how we'd hope, let's move on. But let's not just repeat the same mistake when there's no reason to do so. Further, considering that everyone seems to think that the -policy group have done pretty poorly at their actual job -- maintaining the policy document so that it's readable, consistent and useful -- it doesn't seem like a good idea to broaden its scope. Rewriting it into something comprehensible, making the already approved of changes, and merging all the subpolicies (at least debconf, perl, and python) is likely to be more than enough work for the forseeable future. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpCM38Ezsm7I.pgp Description: PGP signature
Re: The Serious severity
On Thu, May 02, 2002 at 07:15:09PM -0400, Joey Hess wrote: Seems to me that if bug severity is orthagonal to release criticality People keep saying that, but it's not true [0]. Release critical bugs are those that are serious, grave or critical. Bugs that will stop the release of that package are release critical bugs that haven't been specifically exempted by the release manager. Exemptions only happen just before a release, and only happen on a discretionary basis, and don't last for a particularly long time. There may be subtle differences between the meanings of the various terms, but they are *very* strongly correlated, which is right at the other extreme from orthogonality. Cheers, aj [0] It's not even spelt right! But it's Joey, so that's okay. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpHNkJjHKpQg.pgp Description: PGP signature
Re: Working on debian developer's reference and best packaging practices
On Thu, May 02, 2002 at 02:59:36PM -0500, Manoj Srivastava wrote: Julian == Julian Gilbey [EMAIL PROTECTED] writes: Julian People *used* to make that complaint. And if we now move to having a Julian lean policy standards document and a developers reference and a best Julian programming advice document and a dpkg documentation document, we'll Julian have even more complaints in that direction. I beg to differ. The reason people used to complain was there was no single place one could go to to get a definitive reference for all the things a package maintainer _must_ do in order to achieve interoperability and prevent bug reports. Uh, people complain about lots of things. It doesn't make them right, or their suggested alternatives correct. In the new scheme of things, the policy manual would be the place to look at. For further assistance, one could look at the developers reference (HOWTO), The developers-reference describes how to go about uploading new versions of your own packages or someone else's, how stable, testing, and unstable work (once someone actually knows, anyway), how the mailing lists work and so forth. debian-policy currently describes (or, attempts to, or is intended to) the way packages should be constructed when those decisions aren't dictated by the tools. The packaging-manual used to describe the way the dpkg tools worked. Other documents (the update-inetd manpage, the stuff in /usr/doc/debconf, the debhelper manpages, etc) describe how other tools work. This is a far cry from the old muddle and multiple locations for must do things we had in the past. I think you overstate the problems that used to exist. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpEhxnUSFVdx.pgp Description: PGP signature
