Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]
On Mon, Jul 22, 2019 at 01:57:55PM +0200, Mattia Rizzolo wrote: > I don't remember where this was discussed (quite in length actually), > probably debina-qa@ or debian-devel@. It was then implemented in > vcswatch (https://qa.debian.org/cgi-bin/vcswatch) and elsewhere. > I'm positive a result of that discussion made clear there was no such > URI format available already. Do you mean https://lists.debian.org/debian-devel/2016/05/msg00368.html ?
Bug#798476: Returning to the requirement that Uploaders: contain humans
On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote: > What I don't understand in the point of view of the "keep Uploaders" > proponents: What does this information, whether correct or not, > actually give others? Are they going to email or phone these persons > privately when emails to the BTS or the maintainer/team list are > ignored? And what happens if they ignore these communications as > well? I agree. This information is useless, and even if it's not, the source package is entirely the wrong place for it. Let's get rid of the Uploaders field entirely.
Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.
On Sat, May 01, 2010 at 01:31:16PM +0200, Kurt Roeckx wrote: Yes, calling debian/rules directly or using dpkg-buildpackage having the same result is clearly the behaviour we want, which is something we don't have now. dpkg-buildflags should be used by packages just like dpkg-architecture. So I'm in favour of recommending it. Agreed on all points. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100502141429.ga6...@scru.org
Bug#541537: debian-policy: note about sensible-{editor,pager}
Package: debian-policy Severity: normal Due to potential confusion about sensible-utils being only de facto Essential and whether or not packages should be declaring dependencies on it. Something like this footnote may be helpful. diff --git a/policy.sgml b/policy.sgml index bcbaacb..57c5386 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7953,11 +7953,13 @@ done EDITOR or PAGER variables, that program may be configured to use file/usr/bin/sensible-editor/file and file/usr/bin/sensible-pager/file as the editor or pager - program respectively. These are two scripts provided in the - Debian base system that check the EDITOR and PAGER variables - and launch the appropriate program, and fall back to - file/usr/bin/editor/file and file/usr/bin/pager/file if the - variable is not set. + program respectively.footnoteA package making unconditional + use of one of these programs must declare a dependency on + the package containing them./footnote These are two scripts + provided in the Debian base system that check the EDITOR and + PAGER variables and launch the appropriate program, and fall + back to file/usr/bin/editor/file and + file/usr/bin/pager/file if the variable is not set. /p p -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541537: debian-policy: note about sensible-{editor,pager}
On Fri, Aug 14, 2009 at 01:53:28PM -0700, Steve Langasek wrote: Rather than a footnote, I would suggest simply replacing These are two scripts provided in the Debian base system with These are two scripts provided in the packagesensible-utils/package package. I concur. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
On Wed, Mar 18, 2009 at 06:23:55PM +0100, Bill Allombert wrote: For ten years, the common practice was that dpkg-buildpackage did not set any variable. We cannot standardize on the env variable proposal because such proposal has never be made. Instead dpkg-buildpackage was broken in Lenny, and should be fixed ASAP. Now we have packages that do not build correctly with dpkg-buildpackage, others that do not build correctly with debian/rules binary, and all handle env var differently. I concur. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509935: decide whether Uploaders is parsed per RFC 5322
On Wed, Jan 14, 2009 at 10:26:03PM -0800, Russ Allbery wrote: I'm leaning that way as well. I also don't want to require people to use RFC 2047 encoding if they have a name that doesn't fit into ASCII. Anyone have any suggestions on a good subset and description of it that isn't too complex? While I think it would be fine to have a comprehensive and accurate specification, something like this could be an easy improvement. By omitting mention of RFC 822, the mandate for UTF-8 in the control file should obviate RFC 2047 encoding. Despite underspecifying things, I doubt there will be anyone trying to use email addresses of the wrong form. diff --git a/policy.sgml b/policy.sgml index 7de382d..080229c 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2582,17 +2582,14 @@ Package: libc6 p The package maintainer's name and email address. The name should come first, then the email address inside angle - brackets ttlt;gt/tt (in RFC822 format). + brackets ttlt;gt/tt. /p p - If the maintainer's name contains a full stop then the - whole field will not work directly as an email address due - to a misfeature in the syntax specified in RFC822; a - program using this field as an address must check for this - and correct the problem if necessary (for example by - putting the name in round brackets and moving it to the - end, and bringing the email address forward). + If the maintainer's name contains a full stop or a comma, + the entire name must either be surrounded by quotation marks + or put within round brackets and moved it to the end + (thus bringing the email address forward). /p /sect1 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#89038: mime policy copying update-mime(8)
Is it sufficient and desirable to lift the file format description from update-mime(8) and place it into mime-policy.sgml? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#120418: CISE and -fPIC
Camm, Would simply documenting the current glibc behavior with regard to hwcap be sufficient to address your policy proposal? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#122038: inconsistency with /var/backups
Perhaps either the FHS can be clarified or Debian should stop using /var/backups. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#161912: dropping 30000-59999 uid/gid reservation
We could add all or part of this range to the dynamic range. I believe the 2^64-1 reservation suggestion is already covered by the current wording. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH 1/1] Better document version ranking and 0
On Wed, Apr 30, 2008 at 03:10:19PM -0500, Manoj Srivastava wrote: sensible_editor ./debian/changelog # add in ./debian/changes/newfiles You may find it helpful to do a git dch before this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#478850: posh: $ENV variable processed by non-interactive shells
On Thu, May 01, 2008 at 02:33:04PM +0100, Stephane Chazelas wrote: I don't really care about the interactive side of things ($ENV, $PSx, job control), but I tend to consider that for the scripting side of things, the optional features should be implemented. For instance, if you don't have command -v, there's no other reliable way to find out whether a command exists or not. So you have to have something (either command -v or type). If policy wants to mandate either command -v or type, we could conceivably move toward dropping which from debianutils. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473761: [PROPOSAL] debconf specification should allow underscores in template names
On Tue, Apr 01, 2008 at 02:59:33PM +0100, Colin Watson wrote: Package: debian-policy Version: 3.7.3.0 Severity: wishlist The debconf specification says that (/-separated) template name components are limited to alphanumerics, '+', '-', and '.'. However, d-i and I suspect many other packages also use '_' extensively. As a debconf and cdebconf co-maintainer I can say that there's no harm in doing so, and that this should be allowed. Patch against current policy.git attached. Seconded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473019: debian-policy: clarification needed for local builtin exception for /bin/sh
On Thu, Mar 27, 2008 at 01:16:31PM -0700, Russ Allbery wrote: The intention when I originally wrote the text was to not allow declaring multiple variables with one local line, since at the time I was told that some shells didn't support this. I think your first patch is therefore correct and intend to apply it unless someone tells me that my understanding of shellology is incorrect. I observe that a) POSIX specifies the behavior of 'export' and 'readonly' b) Implementation of 'local' is often very similar to 'export' and 'readonly' and in the absence of a standardized 'local', it makes sense to specify a similar form. c) 'export' and 'readonly' both take multiple variables as arguments, assignments, and the -p switch for printing d) the Bourne-type shells in Debian support multiple arguments to 'local' e) the Bourne-type shells in Debian (except for posh) support variable assignments with 'local' f) some of the Bourne-type shells in Debian produce output (which is not necessarily useful) in response to 'local -p', and some produce an error g) bash disallows use of 'local' outside of a shell function I suggest that Policy be amended to require that local a b c=delta e scope variables a, b, c, and e as local, and assign the string delta to the local c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
policy process documentation on wiki
http://wiki.debian.org/PolicyChangesProcess does not appear to be comprehensive. In particular, I note no description of the 'normative' usertag. Please update the page. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote: I suggest to mandate remove all generated files in the clean target (formulated in a way which includes generated by upstream, not only generated by the build target), which implies rebuild everything in the build target. Tell me how I, as an upstream, can use an experimental version of libtool in that situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397939: Lintian: outdated-autotools-helper-file
On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote: Note that libtool is an unusual case here and isn't the same as Autoconf or Automake. The files included in the package (libtool.m4 and ltmain.sh) are not generated files in the same sense. Running libtoolize basically just copies those files from the installed libtool into the package. libtool.m4 is included via aclocal (unless you're not using automake), and then processed into configure by autoconf (unless you're not using autoconf). So if you build-dep on autoconf and automake and try to use sources written for libtool 2.1, everything will break horribly even if you keep the static libtool files the same. We have been stuck with libtool 1.5 for 4 years. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460486: debian-policy: Section 10.1 as a mistake in example makefile snippet.
On Sat, Jan 12, 2008 at 11:22:41PM -0500, Andres Mejia wrote: Package: debian-policy Version: 3.7.3 Tags: patch Debian Policy Section 10.1 contains the following makefile snippet in regards to using the 'nostrip' option. ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif It should be: ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif Are you sure about that? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#172436: [PROPOSAL] web browser url viewing
On Tue, Jan 01, 2008 at 09:08:30PM -0800, Russ Allbery wrote: Here is a patch based heavily on Joey's original patch that describes that. This patch (similar to Joey's) doesn't include the URL canonicalization requirements of the secure BROWSER specification. They don't seem obviously necessary to me and are complex and would add a lot of additional wording to explain how to canonicalize URLs. Comments? Seconds? Solely for being better specified, I think either this or the Compatible definition is preferable to the ESR original. I never use BROWSER myself, so I'm hesitant to weigh in on the other aspects. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian policy manual CVS address?
On Wed, Nov 28, 2007 at 06:19:38PM -0800, Russ Allbery wrote: That's the last change to the canonical repository, yes. I have a bunch of changes queued in my personal repository (including the menu policy update) but hadn't gotten a lot of feedback on whether or not I should just merge them, and have been horrifically short on time recently. patch-1 through patch-10 look decent to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
Okay, here's try number two. I tried to incorporate the feedback from various people. Please critique. Other than wanting the 'echo -n' and -a/-o bits to go away, I think this looks pretty good. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
Forgive me if I am wrong, but I was under the impression that posh was created for the purpose of providing a shell which supports a minimum of functionality required by policy against which scripts could be Not exactly a minimum. For example, posh implements a POSIX pwd builtin. If it were to drop this, one could argue that it still conforms to policy. However, scripts would be running /bin/pwd from coreutils instead, which is not POSIX-conformant, and things like the realpath() function in the tzdata postinst would fail miserably, because it depends on a POSIX feature of /bin/pwd. posh also implements test, echo, and kill, in more standards-oriented versions than those in coreutils and procps. Additionally, it provides true and false for no particular reason. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
Why not ls? Judging by the lack of wishlist bugs requesting it and my own feeling of revulsion at the idea, I'd say that it's because no one wants it. A builtin ls might be a good idea for disaster recovery shells, though zsh-static does not have it. posh is not intended to be such a shell, nor to be particularly useful interactively. Since I cannot think of a legitimate reason for anyone to use ls in a shell script, I think it would add little value. If you disagree, feel free to file a bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy (was: First draft of review of policy must usage)
Here's a proposed patch. What do people think about this approach? I know there was an inconclusive Policy discussion a while back about how best to deal with this issue. As you can tell from this patch, I favor the approach of documenting the specific features that we require and assuming that their semantics are sufficiently clear in practice. + itemthe tt-a/tt and tt-o/tt tttest/tt operators + must be supported/item If people think this is a good idea (and I am not one of those people), then this wording is much too vague. At least one shell implements '-a' and '-o' as unary primaries, whereas what you mean by this patch is almost certainly to mandate support of '-a' and '-o' as binary logical operators. Again, the list operators and || can handle any legitimate need addressed by the -a/-o binaries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding policy (11.2)
It's not about disks so much as bandwidth. Disk may be cheap, but bandwidth isn't, at lesast not universally. I've also no idea who would want or need static libraries in this day and age, but maybe I'm missing something obvious. zsh-static needs a static libc and ncurses sash needs a static libc and zlib busybox-static needs a static libc dpkg needs a static zlib Not sure what else.
Bug#99933: second attempt at more comprehensive unicode policy
and then deleting it gets you in trouble, because zsh does not handle the two byte sequence as one character. Ok. Well, this should not be impossible to fix, I hope. No, just difficult to fix without a nasty kludge.
Bug#174982: [PROPOSAL]: Debian changelogs should be UTF-8 encoded
This proposal is a fairly important yet easy to take first step along the way of transitioning all of Debian to UTF-8. Attached is a patch against the latest version of policy. Seconded. The policy documents should probably be converted to UTF-8 too. pgp1u8pDVFCTE.pgp Description: PGP signature
Bug#160827: syntax of the maintainer name in the Maintainer: field
Why can't we just use UTF-8? There is even (my) pending policy proposal for this #99933, and consensus was that it should be accepted, there are just few (pseudo)issues holding it back. I've read #99933 and #143941, and I see very little that's relevant. What are these (pseudo)issues?
Bug#160827: syntax of the maintainer name in the Maintainer: field
[Branden removed from the Cc after much deliberation] Given that the control file is 7-bit pseudo-822, and has the same issues as mail headers (i.e. presented before any C-T header) is there any reason not to follow RFC2047 for the representation of non US-ASCII maintiner names? I think the objections on this front are that it's not directly human-readable. Of course, neither is Felix Kr�ger, Dagfinn Ilmari Manns�ker, or R�mi Perrot, since I'm using UTF-8. The alternative convention of a or a for ä is only really workable for ISO latin. It's ugly too.
Re: web browser url viewing proposal
that program may be configured to use /usr/bin/sensible-www-browser Inconsistency that should probably be fixed before going into Policy.
Bug#160827: syntax of the maintainer name in the Maintainer: field
True. It could get away with tossing everything outside angulars or inside brackets, though. The address can be mandated to stay 7bit for now. At any rate, people shouldn't be putting raw Latin1 in these fields.
Re: Bug#160827: syntax of the maintainer name in the Maintainer: field
What you want seems to be something that the Policy needs to regulate, I don't want to make Lintian require all that =?iso_8859-2? stuff and thus encourage people to use that. It's moot and the Policy doesn't explicitely mandate the format of the name. I still think it already does, in D.2.4.
Bug#165063: debian-policy: Section `12.8.3 Packages providing a terminal emulator' fails to sufficently document the -e option
Okay, I get it. Yes, clarification is required. I guess we have to mandate that -e be treated as the last x-terminal-emulator option, eh? That won't help with the quoting.
Bug#161455: debian-policy: reference to ash outdated
Package: debian-policy Version: 3.5.7.0 Severity: normal In 11.4: You may wish to restrict your script to POSIX features when possible so that it may use `/bin/sh' as its interpreter. If your script works with `ash', it's probably POSIX compliant, but if you are in doubt, use `/bin/bash'. Debian's ash seems to be renamed to dash now. I suggest changing the clause to with `posh' or `dash', since posh is less forgiving of POSIX incompatibilities.
Re: Bug#161455: debian-policy: reference to ash outdated
/bin/sh is a symlink to /bin/bash. Shouldn't it be an alternative so I can make ash or any other compliant, but smaller shall the default (and thus save memory and CPU requirements)?! The problem is that various people like to claim that policy is either irrelevant or that it means something entirely different than what it says. Furthermore, policy is meant to document current practices, and to mandate current policy, but no one is in any way required to follow current policy, and expecting anyone to do so is antisocial behavior. If there is any discrepancy between current practice and policy, the resolution process involves the tossing of yarrow sticks and the rearrangement of moonstones. Each package must declare its conformance with a particular version of policy. If that package does not properly conform to that Standards-Version, one may file a bug about that. If the Standards-Version is too out-of-date, one may file a bug about that as well. These bugs are used later on in the moonstone ceremony. An increment in the major version number represents a change that will require every package to change. An increment in the minor version number represents significant changes that will require many packages to be changed. Note that the major and minor numbers can never be changed because of the following truths: no one is required to follow policy; policy is not a stick to beat people with; policy dictates current practice; since policy can't change without current practice first changing, and packages can't be required to change, there can be no situations in which packages are required to change. At least, that's if you believe what you hear. Seriously, though, you're welcome to change the symlink from /bin/bash to any conformant shell, as policy will tell you. However, not everything will work perfectly, and bug reports about such problems are met with varying levels of helpfulness and hostility.
Re: what to put in Maintainer fields [was Re: Accepted po-debconf 0.2.2 (all source)]
This can be interpreted as putting the name whatever way you like it, as long as it's followed by the email address which is in RFC 822 format and inside s. Personally I don't see any reason to prevent commas, as we obviously don't need them to separate multiple addresses. If this is truly the case, Policy should be clarified. Then Policy should be changed. What we could do, on the other hand, is standardize on the name format, which would allow us to scrap a bunch of exceptions from the script that generates www.d.o/devel/people. Determining acceptable charsets would be good, too. This goes for the LDAP database entries as well -- most are in Latin 1, but a few are in Unicode, and a bunch of them are ASCII transcriptions too. Those sound like good ideas.
OT: named dirs [was Re: /usr/doc]
[EMAIL PROTECTED]:~doc=/usr/share/doc [EMAIL PROTECTED]:~less ~doc/debian-policy/policy.txt.gz Nice. however how is this different from setting doc to /usr/share/doc and then using $doc to refer to it? The only thing I can see is that it get's expanded if I use tab completion, but that's not a real problem. If you use $doc, it won't get hashed as a named directory. So, in the former case, if you happen to cd to /usr/share/doc, %~ in your prompt escape will expand to ~doc instead of /usr/share/doc. That is, unless you've hashed it already. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
There are minor non-posix issues. The biggest is the use of echo -n(don't say use printf, it's too slow for shoop's target audience). It looks to me like the biggest is the use of 'local', actually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Any chance of a rerun with posh (sources are in queue/new and readable) or pdksh? I don't think you'll be able to gauge posh that way; shoop isn't POSIX-compliant. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
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 It is pdksh. (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 It is posh. 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. So now the arbitrary criterion is breaks on less scripts than ash? gnumail won't run if /bin/sh is ash. The gnumail maintainer should a) make the script POSIX-compliant b) make the script a #!/bin/bash script c) do neither and complain ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
9989 * An alias shall be written as a command line that represents its alias definition. cf. alias: | The following operands shall be supported: | | alias-name | Write the alias definition to standard output. [...] | The format for displaying aliases (when no operands or only name | operands are specified) shall be: | | %s=%s\n, name, value | The value string shall be written with appropriate quoting so that it is | suitable for reinput to the shell. See the description of shell quoting | in Quoting . I read that to mean that the output of alias history, for example, should be something like history=fc -l So, if that's the alias definition, then what's the value of %s, pathname or command when pathname or command is a command line that represents its alias definition. I was assuming that fc -l was the command line representing the alias definition, but if POSIX is documenting current practice, I am in the minority. Still, it seems as though fc -l is more useful in command substitution than alias history='fc -l'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Ah, I see. So, POSIX recognises that there are two distinct traditional behaviours, then specifies something that's specifically incompatible with both of them, and the GNU utilities? No, it's specifically compatible with SysV echo. If it's not to enable backwards and cross-Unix compatability, why do we care about POSIX at all? I don't know. Do we care about POSIX at all? bash, /bin/echo and POSIXLY_CORRECT /bin/echo all treat \c as a literal, for reference. You can file bugs against bash and shellutils if you think they should comply. I suspect this is just talking at cross-purposes, but we do have a certification policyprocedure for changing what's allowable as /bin/sh, viz editing policy and filing bugs and changing scripts. I don't see any reason why that wouldn't be a perfectly reasonable way of doing things, and, assuming we could avoid having the bugs gratuitously closed or flamewars about them, I'm optimistic you'd agree. Isn't that what we're doing? Certainly: I'd've assumed the same. It turns out we're wrong: our scripts don't work with random POSIX-compliant shells, just with bash and ash. But they don't all work with ash. Which is all very well if it's just one script, but it's not so great when it's a whole bunch of scripts in a whole bunch of packages. That's why we have a special case for mass-filed bugs: discussion and consensus *first*, to make sure that that policy is what we actually *want*. Calling it a mass-filing is a stretch, especially since I did them all manually. I've never tried it, I haven't seen anyone else try it, and given that there are a significant number of issues generally, I'd expect some of them to cause pdksh problems. Additionally, I haven't seen anyone give any reason why they'd want pdksh instead of bash or ash. Well, if it'll help, I'll try. bash is large, and is slightly POSIX-incompatible. ash is slightly POSIX-incompatible. pdksh seems to be more POSIX-compatible than both right now. But let's skip that right now, since POSIX compatibility is in question, and I'm confident that Herbert will have ash up to snuff shortly. I would estimate that the vast majority of severity:serious justification:11.4 bugs being filed on packages contain bashism in the subject and cite brace expansions being used in #!/bin/sh scripts. While it's called a bashism and is definitely not POSIX-compliant, all the other Bourne shells currently in the archive support brace expressions. That includes pdksh. In summary, pdksh vs. bash gives you some of the size and speed advantage and more bashism compatibility than ash vs. bash. Perhaps it's a compromise solution for those who want a smaller /bin/sh but don't want the breakage. Debian's about choice: if someone wants to rm -rf /usr/bin/perl*, are you going to prevent them from doing so because you're in love with perl and you're going to marry it? That's a great question. That, however, isn't the question being discussed. The question is whether I'm going to *support* them in doing so: fix problems that wouldn't have existed if they hadn't done so, or avoid creating them in the first place. Well, no one's forcing you to comply with policy. The other question which I've been implying for a couple of messages now, is if we do support them, how should we prioritise it in relation to other issues. And the answer to that should be, IMO, nowhere near as highly as DFSG-freeness or security problems. Fine. Fix all the DFSG-freeness and security problems in your packages, then change those daunting 6 octets. Well, whether Linux 2.5 is nice or not seems pretty irrelevant. Of course it does. If it seems so bizarre, perhaps it's an indication that you're not grokking what I'm saying. I'm not even close to grokking it. You've already given one example where bash is *more* compatible as /bin/sh than alternatives (ie, (some versions of?) the Linux 2.5 kernel), More compatible with the Linux 2.5 kernel build system. More compatible with Debian #!/bin/sh scripts right now. Less compatible with certain ATT shell scripts, which special-case bash's allegedly buggy behavior. Obviously no users running the latter really need something other than bash as /bin/sh, so I can see that as being unimportant. and I'm far from knowing much about POSIX, but the specification for echo doesn't seem to be doing much to improve compatibility, as far as I can see. No, the previous specifications haven't done much for compatibility. They said we don't have a clue what echo will do when you give it crazy things like arguments, so use printf instead. Only nobody used printf. Why? Because echo is typically a builtin, and printf is a builtin in only a few shells. Now, if echo doesn't behave the way they say, it's buggy. This makes it suddenly useful for POSIX script writers. I imagine that it might be useful for people importing scripts from SysV too, but who really cares about that? I
Re: RFD: Essential packages, /, and /usr
Easy now. I don't *like* the construction if command -v foo /dev/null 21; then foo fi I hate that nasty redirection that is imposed on me. Well, the popular proposal (which seems to be SUSv3+UP+XSI), will give you type, and you'll need to redirect that as well. If you want some sort of -q option, you'll need something else entirely. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
If this is regarding the [ -a -o ] stuff, then sorry, but debhelper is just the tip of the iceberg, or at least of my personal iceberg. Hmm.. I must have grepped badly. There will be tens of thousands in all of debian, if this sample of 100 packages is representative. I even find them in autoconf install-sh, which I'd expect to be portable. I've emailed automake about this. Perhaps they'll change it. Perhaps not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
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. So, if someone needs to run a low-memory machine in production, and is not interested in finding brace expansions in #!/bin/sh the hard way, it's safer to use pdksh as /bin/sh than it is to use current ash, and you will still get a memory benefit. Is this not an answer? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Are you referring to the extra new line that ash outputs after an alias? If so that is indeed incorrect and will be fixed. I also interpret the leading literal alias to be incorrect. It's less useful, at any rate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I don't really care whether it should or shouldn't be so, but it certainly seems like it *is* so. Using bash minimises the disk space used by shells and is the most reliable, and using ash is faster. Are there any other benefits to be had by using different shells? Using pdksh will give you better POSIX compliance, though it looks as though Herbert is working to solve this as we speak. Using posh will give you better POSIX compliance and facilitate system breakage. Using zsh, well, I don't know why anyone would want to do that. Same goes for ksh93. I'm not really sure why you're being quite so emotive as to call it an arrogant lie. I'd've called it a bug or an underspecification. Potato, potatoe, I guess... So you maintain that policy really says that /bin/sh may be either bash or ash, and nothing else. And in any event that's my point: if you find a case where packages don't match what policy says, you need to bring it up on -devel to make sure it really is policy -- well, your reading of policy -- that's right. I brought up command -v on -devel. What was the outcome of that? And it worked pretty well, don't you think? Allowing people to use ash as well wasn't too huge a step, so we made that. We overreached and thought what we were doing would let people use random other shells as well, but obviously we were wrong. Whether we want to go further is something that we may wish to do, or we may not. As I recall, the ash-blessing was not as pleasant as you imply. (Considering that Linux systems tend not to run non-Linux binaries, that commercial apps tend to not come as shell scripts, and that most Linux distributions come with bash as /bin/sh, I can't say it's a very credible problem) Most commercial apps that I've seen come with shell scripts, yes. Some Linux 2.5 kernels won't compile if /bin/sh is ash. Is the bug in ash? beyond Our users and free software perhaps). Filing release-critical bugs is exactly that, though: forcing everyone to accept your priorities as the most crucial things affecting their package. Sometimes that's You do realize that there's precedent for filing policy violations as serious bugs, right? with. At other times it's just ridiculous: being able to use zsh instead of bash as your /bin/sh might be a neat trick if you're a zsh fanatic, but it isn't any sort of significant practical win to anyone. No, being able to use a POSIX shell instead of bash as your /bin/sh is a significant win. One way you have a clearly defined interface. The other way you have aj saying that really just means bash or ash. No, I won't: what you've done for me is given my a little patch which affects essentially no one, and given me a dozen new bugs in the RC bug list that I'm going to have to go through and downgrade or close. Sorry, but the plusses don't cancel out the minuses. So, in other words, maintainers shouldn't fix bashisms in #!/bin/sh scripts either. With the new POSIX / SUSv3, we've found we need to add another exception along with echo -n -- that we need the (non-interactive part of the) UP featureset in order to ensure the type command is available. We have? type isn't part of UP; type is XSI. Furthermore, if, in fact, we need this exception, it should be added. If, on the other hand, we need policy to say scripts must be compatible with both ash and bash, then the UP and XSI stuff is irrelevant. Huh? Why would you think that? Debian will be better if it releases faster. Debian will be better if it's security improves. Debian will be better if all the neat new GUI apps blahblahblah. Does it make more 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. This entire paragraph makes even less sense to me. Well, you're welcome to enlighten me at any time. Do you see a problem with a policy of packages only need to work for the maintainer? 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. Why haven't you filed such a bug against policy? I think you should not, actually, since changing both to should would make the whole concept utterly pointless. Perhaps you see value in the following scenario: aj uses bashisms which don't work in ash in all his #!/bin/sh scripts. Clint uses ashisms which don't work in ash in all his #!/bin/sh scripts. Apparently, now, neither shell can be used as /bin/sh. Both file bugs, and are told to fuck off. Everybody wins. 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. Occasionally, citizens of certain countries
Re: RFD: Essential packages, /, and /usr
In the case of command -v, the alias prefix is required. Reference? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
2. There are some features which are regularly used in maintainer and other scripts which depend on them, e.g., the options -a and -o, as well as parentheses for the test command or [. the obsolescent forms of kill and trap: kill -INT or kill -9. I've already filed some bugs on 'trap'-misusing packages. test -a, -o, and parentheses could easily be replaced by and-or listse -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Forbidden by POSIX: I see. I'll correct the test. The exact output of command -v is not given by POSIX. I believe it says When the -v option is specified, standard output shall be formatted as: %s\n, pathname or command Am I looking in the wrong place? More details please. %s=%s\n, name, value -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
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. Instead of a one-line fix, histrionics, bug-closings, and references to Solaris seem to be in order. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
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? Then when people file bugs, I say Haha, fuck you; it works for me. 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*. I see. You don't see adhering to standards as being effective. Let's see. 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. Why is one choice not obviously preferable to the other? 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. Policy is useful in that it ensures consistency and interoperability. Or are you suggesting that the policy document is really just a shadow of some real policy that exists only in the minds of the developers? 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 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. Surely we're all here looking for the *right* way to do things, not merely the documented way. Of course. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
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 on earth should this be so? Is saying The standard shell interpreter `/bin/sh' can be a symbolic link to any POSIX compatible shell, if `echo -n' does not generate a newline. yet another of Policy's arrogant lies? How are users to know that this is a farce? It's only a farce, mind you, because of people who think compliance is a bore. When I joined Debian, bash was the only choice for /bin/sh. Back then, one would have said, Script works on bash, which is the only shell anyone as a reason to use as /bin/sh on Debian, and we don't support anything else. Now, those poor people who read Policy or debconf messages might come to the silly conclusion that they could make pdksh or zsh their /bin/sh. Or perhaps they will obtain a copy of ksh93 and make that their /bin/sh. Perhaps that are even forced to do that to support some horribly-behaved commercial software. Some developers want our users to have this choice. Others don't have this as a priority. 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 Then you'll appreciate that I did the work for you and gave you a POSIX-compliant alternative in the bug report. 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. I don't get that impression. POSIX actually seems to be improving with time. 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, I'm sorry; is woody not released because I'm not spending my time working on GUI apps? 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, 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. If you really believe that the 'must' is a typo, why don't you reopen the bug and reassign it to debian-policy where that typo can be corrected? 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. If you have inside knowledge that these scripts have ashisms, you can avoid the headaches which would plague you had you believed Debian's policy document. 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, 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. 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. No, it's evidence that stuff isn't POSIX-compliant like it claims to be. A feature is needed just because someone uses it? kill -9 is needed because you don't want to type -s ? 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. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I do not see why we should use which. As I have stated previously, we already require feature sets (set -e in particular) in the new POSIX document which imply the existence of type(1). So type should be Can we codify this better? the preferred utility for this task. Besides, as an external utility, which(1) does not know about shell builtins, which is actually bad. This depends on the user's perspective. I can't imagine ever wanting to do anything other than 'test -x /absolute/path' in a postinst. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I can. I just want to know if the command is available for my script to use; I don't care about the latest flamewar that moved it in or out of /usr or */sbin. You are searching for a particular word, and that word may represent a binary/script, a shell function, a shell alias, a shell builtin. There may be many of the aforementioned things with the same name. No mechanism exists to determine whether or not these things perform similar actions or have similar interfaces. Let's say that I want to run deathrampage in my postinst. deathrampage is a binary in a package of the same name, and this is the deathrampage that I wish to have executed. There are many ways for me to check for it: (A) deathrampage || echo uh-oh, continuing without it Advantages: portable Disadvantages: requires running the program in question (B) test -x /usr/sbin/deathrampage /usr/sbin/deathrampage Advantages: portable, will not execute the wrong deathrampage unless someone has placed an impostor in /usr/sbin Disadvantages: will fail silently if deathrampage is moved to /usr/bin (C) multiple tests, or loop of tests Advantages: portable, will handle multiple finite locations Disadvantages: will fail silently if deathrampage is moved beyond the finite list of locations (D) command -v deathrampage 2/dev/null deathrampage OR type deathrampage 2/dev/null deathrampage Advantages: will find and execute deathrampage anywhere Disadvantages: will find and execute deathrampage anywhere, no matter if it is an alias to 'rm -rf /', a shell function that initiates immediate reboot, or some other bizarre and unexpected thing. Not POSIX-compliant. (E) which deathrampage 2/dev/null command deathrampage Advantages: will find and execute deathrampage on the command search path. Disadvantages: not standardized at all. builtin which's will not likely have the same interface. (F) /usr/bin/which deathrampage 2/dev/null command deathrampage Advantages: will find and execute deathrampage on the command search path. Disadvantages: requires faith in /usr/bin/which not moving or changing (G) dpkg -S deathrampage some other stuff Advantages: will only find deathrampages tracked by the Debian packaging system. Disadvantages: slow and cumbersome (H) #!/bin/specific shell, and use known whence, which, type commands Advantages: no portability problems, and you might get exactly what you want Disadvantages: annoying to users everywhere (I) invent a Debian-specific solution to this problem Advantages: less confusion Disadvantages: requires cognition, and people seem to feel differently about whether or not they want random shell aliases, functions, and binaries in /usr/local being executed by package scripts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
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 people will cry. The other problem, then, is that we will have a situation wherein no shell in Debian would be suitable as /bin/sh (unless I'm assuming incorrectly about pdksh). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Codify what, please? I personally use which, since it is provided by am essential package, and I can live with it eing an external program, and missing aliases. People can also use POSIX type You don't have that with zsh, since which is a builtin. (umm, does zsh have type?). Why does this have to be codified? When zsh has type as a builtin, though it isn't POSIX either. do we want to stop codifying every little thing? When there are no more problems? There are numerous #!/bin/sh scripts in Debian that are not POSIX-compliant. One might get the idea, if one were to read Debian's policy documents, that these scripts violate Policy. One might also get the idea, if one were to read the same section, that one could install a POSIX-compliant shell as /bin/sh on one's Debian system, and that one would experience no difficulties in doing so. Of course, this is a fallacy. What is the common sense thing to do? I would say that it's to have bash as /bin/sh, since that's what most maintainers are using, and that's what's most likely to work with the most scripts. I, on the other hand, would rather have ash as /bin/sh. What makes this possible? That policy has codified the requirement for /bin/sh scripts to be POSIX-compliant, and ash, for the most part, does a good job executing POSIX-compliant scripts. If this were not codified, and we were still living in the dark ages when someone would be lynched for using ash as /bin/sh and having the gall to expect sympathy, then well, lynching would be the least of problems. I would possibly classify hard coded paths a bug in the package, since I may well be experimenting with PATH's. But hard coding paths is just asking for breakage, in case the FHS or the LSB or someone decrees the binary move. Since there is no need for such hard coded paths, doing so is bad design. And not doing so invites unexpected behaviors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
The irony is that the only reason to use which is to accomodate speed freaks who want to be able to use non-bash shells. Now they get hit by the bash startup time anyway. And those same speed freaks are likely to be using ash, which has both type and command -v. I believe that Herbert's proposal solves this. I once again recommend a deathmatch between ash and zsh fans. Let the best shell win. bash doesn't even get to compete? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
But if you doi want to run it, this is it,, end of story. So, now for when we want to merely test for presence. Perhaps if you want to test for multiple commands before executing them? So what? Who the hell is the postinst to tell me what I should or should not be doing with my machine? When I change the command on Apparently if you have zsh as /bin/sh and try to install xdm, the postinst will happily tell you what version of debianutils to install to get readlink. my machines, by gar, stupid postsinst should follow suit. Where does this overweening sense of the postinst always being right, the human who has changed the environment always is wrong coming from? This is certainly not the UNIX philosophy. If you wanted to replace the update-menus command, you would have much more success by dpkg-diverting it rather than putting your replacement in /usr/local/bin. I don't believe anything guarantees that the latter will work, whereas the former is a good bet. Silly, since A is the correct answer, but what the heck do you mean it is not standardized? POSIX is a standard, you know, and it has indeed standardized this. It has not. The closest POSIX comes to which is to mention that it came from csh. If we do not need to run the command, this is the answer. which is provided by an essential package. which has a well known standard behaviour. Does it? Last I checked the manpage did not accurately reflect the actual behavior. If builtin which does not follow POSIX, file a bug. First you'll need to get it into POSIX. Silly, since either A or E would do the trick. For all Bournish shells in Debian of which I am aware, yes. Oh yeah, the Not Invented Here syndrome. POSIX exists, and works for everyone else except Debian. Branden, for example, does not appear to be pleased with the options POSIX provides him. Can we please take this silly thread off policy now? I imagine that amending policy would help that end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
I don't have what? which is present, either as a builtin, or provided by an essential package. What exactly do I not have? You don't have a standard interface. Any POSIX-compliant shell could easily implement a 'which' builtin that returns success no matter what. This would not violate POSIX. This would not violate Debian policy. Some postinsts might stop working properly. Common sense might save you on this one. Oh? How is it not POSIX? type is X/Open. Then we should stop right here, since that is an impossible goal. That doesn't necessarily follow. Yes. File bugs. It would be silly to mass-file bugs if there's going to be a modification of policy in the near future. File bugs. fix things. More documents saying this is wrong does not fix any bugs. Policy already talks about POSIX /bin/sh, yet another document just adds to the ossification, and solves nothing. You seem to be happily ignoring the fact that certain people object to the dearth of features in POSIX sh. Yeah, lefe sucvks, doesn't it? And damn Heisenburg. Lefe certainly does sucvk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Umm, say what? You mean you want to test for presence of multiple commands and execute one or more? (not something you covered origiannly, but in that case go to case H I'm hypothesizing. I can think of no real-world examples where I'd need to do anything fancy here. And what is the root cause of this problem? Seems like this is a bug somewhere, and should be fixed. The root cause is POSIX-incompliance in the postinst. 'command -v', in particular. Yes, if proposals like yours take effect. Stuff that has worked for 30 years in UNIX is just to be tossed aside. NIH. No, not if. Now. Try it. You'll get very inconsistent results. Fair enough. It is an utility provided by an essential package, and has a man page. If that is not good enough, use type. Surely people can manage their packages without having everything in policy? If I am filing bugs against scripts that use 'command -v', I'm certainly going to file bugs against those that use 'type'. I am not sure this is likely to happen. I certainly do not see a consensus emerging. You may have better luck getting it into the Best Practices book. I have no interest in getting these extensions mandated. I would prefer that either the scripts or policy move toward the other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
How are we to prevent this anyway? Who says any of the other solutions can't be botched like this? The difference is that I, as a user, would never expect for a postinst to look for something called deathrampage, and by extension, would never expect for a postinst to suddenly be running the 'deathrampage' script I put in /usr/local/bin for later carnage. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Is POSIX + extention. How is this relevant? Yes, it does. There are never going to be no problems. Oh, I see your logic. Therefore, we should never solve any problems. Unlikely. The best you'll get it POSIX+extention, and that still means command -v is a bashism. Depends on the extensions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
So why are you putting something in roots path ahead of the standard path unless you want it to be run? Under what circumstances? In which context? root has different paths at different times. I think that is a bug. I think that is a feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
The scripts should not, and this is why hard codiong paths is a bug. A policy violation, or just a bug? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
XSI. IEEE Std 1003.1-2001 describes utilities, functions, and facilities offered to application programs by the X/Open System Interface (XSI). Functionality marked XSI is also an extension to the ISO C standard. Application writers may confidently make use of an extension on all systems supporting the X/Open System Interfaces Extension. Are you suggesting that Debian support this extension, or a subset thereof? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Yeah, well, I'll be happy to change this once we have some official Policy, or an offical Best Current Practice statement. We DO have an official Policy. It makes 'command -v' unusable in #!/bin/sh scripts. That's 688 packages in violation. It makes 'set -e' unusable in #!/bin/sh scripts. That's 6810 packages in violation. At least 7498 packages in sid have preinsts, prerms, postinsts, or postrms which violate Debian policy. Manoj suggests that I file bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
The policy explicitly mentions that set -e is to be used. Have we collectively taken leave of common sense? No, it mentions that set -e SHOULD be used in some cases. The fact that it mentions /bin/sh in context with 'set -e' might be a bit confusing, but I don't think that that overrides the declaration that #!/bin/sh scripts MUST not use set -e. For the former. For the latter, if it really confuses soemone whether set -e is to be used or not, I suggest they stop being a developer and take up some other hobby, like being a lawyer. There's no confusion. set -e is expressly forbidden. Perhaps those persons who prefer forbidding something while claiming that common sense allows it, to achieving some sort of consistency, should become lawyers or perhaps government officials. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Ah. Before I provide my impramatur of approval over words that shall be writ in stone, are there any shells that have POSIX+XSI extensions+UP-in-interactive-mode? If so, this could be a useful criteria. If there are no such shells, well, we live with what we have, and reassess when POSIX compliance is reached. I've whipped up a little test suite, to assess POSIX compliance. It is by no means near complete. The shells tested: ii ash0.3.8-37 NetBSD /bin/sh ii bash 2.05a-11 The GNU Bourne Again SHell ii pdksh 5.2.14-6 A public domain version of the Korn shell ii zsh4.0.4-43 A shell with lots of features. ii zsh-beta 4.1.0-dev-4+cv A shell with lots of features (dev tree) This is for SUSv3 compliance. The number represents lines of diff output from the proper output. These lines are not weighted, nor do they reflect a number of violations. ash 33 bash10 bash (posix mode) 10 ksh 5 ksh (posix mode) 5 zsh 30 zsh (sh mode) 20 zsh-beta28 zsh-beta (sh mode) 18 Now, for SUSv3 + UP + XSI: ash 42 bash20 bash (posix mode) 18 ksh 9 ksh (posix mode) 9 zsh 36 zsh (sh mode) 26 zsh-beta34 zsh-beta (sh mode) 24 I should note that the 5 for ksh represents conformance with Debian's echo policy. I'll put the tests on http://people.debian.org/~schizo/ in case anyone's interested. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Back it up, buddy. Where is your proof? I have given three explicit references from policy strongly recommending set -e. Where the heck is it forbidden? Apparently due to sleep-deprivation, I confused Herbert's assertion with fact. It's set -h that's forbidden. Debian does not need XSI for set -e. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Look for the -e option for the set utility. Yes, yes. Historical reasons. Ah, so then in that case, it makes sense to require 'echo -n' from /bin/sh, while forbidding it in /bin/sh scripts as part of a migration strategy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: command -v in postinsts violating policy
The simplest way, of course, is to state in the release notes that zsh, although POSIX-compliant (is it really?) should not be used as Is bash really POSIX-compliant? Is ash? Is pdksh? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#148172: command -v in postinsts violating policy
Such as? test -x /usr/sbin/install-docs || echo hi ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: command -v in postinsts violating policy
the problem is there is no better replacement for 'command -v'. And we do not really need an exception -- every shell we have supports this. So the only way Well, that's not true. As Luca has pointed out, /usr/bin/which is Essential at the moment. Also, not every shell in Debian supports `command -v', as was pointed out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: command -v in postinsts violating policy
IMO, anyone who uses zsh for /bin/sh is quite insane. ;-) Perhaps, but it's been done. And policy in its current state fraudulently claims that it will work. Why we can't resolve this in a simple way is beyond me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: command -v in postinsts violating policy
Does Debian explicitly support such a configuration? That's the point. I can symlink /bin/sh to /usr/bin/tcsh or /usr/bin/X11/XFree86 if I want, but that doesn't mean that the Debian packaging infrastructure offers to it for me via a debconf question, update-alternatives, or some similar mechanism. This is relevant how? Policy is not being followed. In sid, we can easily change policy, or we can easily change package scripts. In woody, anyone who links /bin/sh to a shell allowed by debian-policy, whether Debian zsh or a shell which they have compiled themselves, may be suddenly deprived of installed documentation and other random things. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#148172: command -v in postinsts violating policy
That's different and more fragile: it relies on a fixed path which command -v does not. Is this important in the event that install-docs gets moved, or so that someone can put a different install-docs in the PATH? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: command -v in postinsts violating policy
No one is advocating such a position. It is a hallucination of your fevered mind. My mistake. I could have sworn that several people suggested turning a blind eye. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new fields in debian/control
If it turns out to be generally useful, should we not at least consider building it in, rahter than asking everyone to hack their own variant? I think that the Origin is corelated to the BTS, and the BTS is trongly related to the style, and this should be reflected in the implemntation (make the common things easy). I think we have different ideas about the point of the Origin field. If you set up debian/rules to conditionally build for FSSTND, FHS 2.1, or FHS 6.57 depending on which release of Debian you happen to be targeting, you won't be changing the origin. So why make it easy to say -O Vitamin-D but not --distribution slink? Environment variables work just fine if you want to change behavior without editing files. This is a very narrow view. I often have local packages, I try them out as experiments, and may well have different policies, build depends, etc for when they are local, as opposed to when they are uploaded by me to Debian. So you'll want to put conditionals in debian/rules for your own personal policies to be followed whenever Origin is set to 'local' and then leave this in the package you upload to Debian? So if you want your manpages in /opt/local/var and your config files in /usr/local/lib, you can just do -O local or -O manoj? Then if I want to build a customized version of your package with the manpages in /usr/share/man and the config files in /usr/local/lib, I have to edit debian/rules and either create my own origin-based conditionals or modify yours. On the other hand, if you use environment variables, I could simply do something like DEB_BUILD_CONFIGFILES=manoj dpkg-buildpackage -blah -blah -blah If tweaking the design allows this wider usage, why should we not do iut that way? ANd, incindetllay, I think one should have origins be handled the same way dupload handles upload locations: each origin could have its own preset BTS field, etc, and as long as I am happy witht he defaults, I can switch from local + tested to debian upload with no changes. If there are going to be no changes between Origin: local and Origin: Debian, and you're not going to be distributing the deb, then what is the point of setting Origin: local? To prevent yourself from filing bugs against your own package?
Re: new fields in debian/control
I could definately see where you do 'dpkg-buildpackage -O debian' or 'dpkg-buildpackage -O corel' What? Why would anyone want a proliferation of packages that are identical except for one control field? If Plagiarism GNU+Linux wants to take my package, modify nothing except the control file, what purpose does it serve to have bug reports go to them instead of to me? In fact, what purpose does it serve to even have the duplicate package at all? If, on the other hand, they're actually going to modify the packing so that all binaries live in /usr/local/var, then they should modify the Origin and take credit for their genius.
Re: new fields in debian/control
Who said anything about that option only affecting the fields Wichert mentioned? Think about debian/rules that look for what origin they are building for, and take appropriate action. If you're going to use debian/rules to do conditional building for multiple origins you may as well conditionally set the Origin:. I imagine you could use check an environment variable and then place the appropriate variable in debian/substvars.
Re: Packages should not Conflict on the basis of duplicate functionality
No, this is silly. When you install a package, it is for use. If you don't intend to use it, why install it? Perhaps you can explain where this idea comes from. Of course, if I want to evaluate a daemon, I can --unpack the package into /usr/local/testfun and manually enable it, evaluate it, and then rm -r it. Sure, that's possible. And I can also compile it myself from dsc and munge the install scripts. Or I can build it from pristine source and stick it in /usr/local. So clearly nothing is preventing me from reaching my desired ends even if it prevents the preferable means. But I install packages I don't intend to use. On certain systems I'll install tcsh or csh. I have no intention of using them (this is aside from any package that might require a csh provider), but there is the potential for a user to want tcsh there sometime in the future, and if he is not clueful to get it on his own, he'll be okay because it's there. Having a shell package going and changing users' shells on install would be horrific, though I doubt anyone would dispute that. There are daemons that can be run legitimately by a user on high ports. Let's say you have a system where you let people run web servers in user space. Luckily, roxen and apache don't conflict with one another, so you can easily have both available for users to use, and edit the configs so that neither of them run on port 80 or any other system port. The daemons are being used; they're just not being used in the standard configuration. On the downside, one cannot reasonably assume that if one installs both packages that roxen will grab port 80 on bootup. If you have packages conflict, then yes, you can be pretty certain that the pop server you've installed is the one that will be grabbing port 110 on all IPs, because any other pop server has been removed. So if the consensus is that debconf should handle it, why don't we stop the flaming and whining and figure out the logistics of the matter?
Re: Packages should not Conflict on the basis of duplicate funct
Ok, let's bring this back to implementation. How would you propose we handle this? Currently daemons install, set themselves up, and begin running. a) we can prompt. b) we leave everything off and let the admin turn it on (not an option for obvious reasons) c) first come first serve -- first daemon installed does its job, the rest install unconfigured any others? d) have something that keeps track of installed services, perhaps with priorities akin to alternatives. If there weren't an issue of services being run either in inetd or standalone, this could be accomplished with a souped-up update-inetd.
Re: Packages should not Conflict on the basis of duplicate funct
I'll stick my hand up for option (c). The effort involved in modifiying configurations is marginal. And by what means does the package determine whether or not another package has gotten there first?
Re: Packages should not Conflict on the basis of duplicate funct
Are they automatically setup [ the 4 auth ports ] or is some manual intervention required? The server to which I referred is runnign FreeBSD. Nothing is automatically set up.
Re: Packages should not Conflict on the basis of duplicate funct
a) I would not test a new daemon on a working machine, I would use a separate So? b) if you know what you are doing, compile the packages by hand, fix their install scripts, and remove the conflicts. You are trying to circumvent the norm. If I wanted to compile them by hand, why would I even bother with the Debian packaging system? Debian is operating on making the easy case easy. 90+% of our users want to just install a package and go. Perhaps we would have more users if we didn't maintain such a mentality. 90+% of our users probably don't run production servers. Is there some reason you don't want to cater to 100% of our users if possible?
Packages should not Conflict on the basis of duplicate functionality
The apparent solution to something like bug#45344 is to have all the packages providing an identd to conflict with one another. While reasonable in most cases, this has the horrible side effect of not letting the administrator have multiple identds on the system. What if I have a machine with three IPs bound to its primary interface and want to run midentd on one, oidentd on another, and pidentd on the third? Well, first of all I would have to replace Debian's inetd with something more configurable, but then I would be forced to deal with the package manager, which really should have no business preventing me from having as many implementations of identd as I like. Perhaps identd isn't an example to be taken seriously. So let's say that I have a POP server. I want to have qpopper running on port 110. Then I want cucipop running on port 995 through stunnel for users who want to use SSL. Then I want to run gnu-pop3d on a high port for testing purposes since it's brand new and I don't want to throw it into production without testing it first. What happens? Well, nothing, since all three packages cannot coexist peacefully. qpopper has nothing to say about the matter, but cucipop expressly conflicts with it, in addition to conflicting with pop3-server, which both it and gnu-pop3d provide. These packages don't conflict; they merely provide the same service. There is no reason that these three packages cannot coexist on the same system. Any namespace overlap can be solved by alternatives or renaming, as such things are normally rectified. Debian policy should proscribe such inconveniences.
Re: Packages should not Conflict on the basis of duplicate functionality
Of course. Now if you built them yourself, dpkg wouldn't touch them. If I wanted to build them myself, I would use Slackware. If I repackage them I will need to remove the Conflicts line from the control files every single time I upgrade. People who want such complex setups should have enough sense to be able to figure out how to make them work, without imposing additional difficulty on the maintainers for such a rare case. There is not generally a use for more than one POP server, ident server, mail server, etc. I can find exceptions, but it isn't Debian's job to make every possible configuration easy, just the most likely and typical ones. The most likely and typical configurations are those for a home workstation. So let's screw anyone who wants to use Debian on a production server. I run apache and roxen on the same machine. That's hardly typical. Why on earth would anyone want to run two different web servers? These two packages should obviously conflict since they're both web servers and want to grab port 80. They both provide httpd; should I file bugs against them demanding that they conflict with it too?
Bug#45307: PROPOSAL] virtual package ident-server
The proliferation of ident daemons (midentd, oidentd, pidentd) in Debian necessitates the introduction of a virtual package that these packages can provide and conflict with (since you can only [reasonably] run one ident daemon at once). While ident-daemon seems more intuitive, the name ident-server is more consistent with existing conventions for daemons. Per the virtual package policy, this is CC'd to debian-devel. While this is fine to satisfy dependencies, the packages would be more useful if they provided a standard interface via the alternatives mechanism.
Re: Bug#39299: PROPOSAL] permit/require use of bz2 for source packages
Ideally if the package is released upstream as a .gz we should use the .gz. But when it's released as .gz and .bz2 as many things now are, we should probably use them. And what if it's released upstream as a .tar or a .tar.Z?
Re: Bug#23000: no way to force deliver over procmail
If I may, why is sensable-mda not an /etc/alternatives thing? The problem is that deliver and procmail take different arguments. If not present, sendmail is able to deliver itself and if present it should use the MDA which scores the highest on update-alternatives OR local admin's choice of MDA. procmail, deliver, and mailagent(? I've not used..) should all be alternatives for sensible-mda and ranked probably procmail, mailagent, deliver by default. (Sorry Manoj, but procmail is less of a surprise as an MDA than mailagent IMO..) I would be in favor of an /etc/alternatives mechanism that used a wrapper for each MDA. That way all MTAs could depend on an MDA virtual package. You get the functionality of sensible-mda with the configurability of symlinks. Of course, I'd still override sendmail to use procmail directly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
