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
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
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
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
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 --
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?
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.
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,
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,
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
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
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
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?
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
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
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
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,
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
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,
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
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
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
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
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]
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
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
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
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
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]
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]
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]
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]
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
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,
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
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,
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]
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
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.
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
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.
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]
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
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
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
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
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
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
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
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
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
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
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;
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.
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
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]
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
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.
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
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
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
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
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
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,
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
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
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
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.
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
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]
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
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
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
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
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
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]
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
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?
[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
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
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,
/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
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.
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.
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.
that program may be configured to use /usr/bin/sensible-www-browser
Inconsistency that should probably be fixed before going into Policy.
[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
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?
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
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.
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
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
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
93 matches
Mail list logo
