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 t
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
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.
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 sensible-utils package".
I concur.
--
To UNSUBSCRIBE, email to d
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 100
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
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 com
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]
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]
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]
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]
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
On Wed, Apr 30, 2008 at 03:10:19PM -0500, Manoj Srivastava wrote:
> sensible_editor ./debian/changelog # add in ./debian/changes/
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 PROTECT
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 p
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
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, 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 cop
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".
T
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
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 nec
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 t
> 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? Contac
> 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, no
> 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 wer
> 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
> assu
> 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 st
> > 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.
> 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
> 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?
[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
> that program may be configured to use /usr/bin/sensible-www-browser
Inconsistency that should probably be fixed before going into Policy.
> 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.
> Preserving would be useful if there were a lot of users or programs
> taking the content of the maintainer field and stuffing it into a To
> header. I know of no programs doing that and regarding users, I think
> we'd rather deprecate the practice in favor of {packages,bugs}.d.o.
One program tha
> 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
> 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.
> /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 somethin
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
> 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 tru
> > [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, bu
> 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? Con
> 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
>
> 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]
> 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 expli
> 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
> Easy now. I don't *like* the construction
>
> if command -v foo > /dev/null 2>&1; 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
> Yeesh. I don't know what so hard about this. The following statements are
> true.
>
> I am not an idiot.
> I do not need to be forced to follow good advice.
> Policy is by and large good advice.
The preceding three statements are subjective. I think it's good advice
for the X
> 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 compatabi
> 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 (
> 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]
> Having echo aliased to `printf "%s\n" "$*"' would give you better POSIX
> compliance too.
No, in fact, it would not.
Compare the output of
ash -c 'echo "test\c"'
versus
printf "%s\n" "test\c"
> There's a reason why we specifically *don't* do that.
You mean, other than the fact it won't wor
> 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 yo
> 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 "unsubscr
> 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 "T
> 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 shou
> 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
> Sure, so could command -v. The problem is with the amount of scripts
> that use them.
Once most packages are recompiled with newer debhelper, the command -v
problem should pretty much disappear with the exception of of Branden's
packages.
I've already received positive feedback on most of the
> 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",
Am I looking in the wrong place?
> More details please.
"%s=%s\n", name, value
--
> 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
> Please be more specific.
ash:
does not handle multiple heredocs
read-write fd's do not behave usefully[1]
treats $10 as ${1}0
does not support cd -L
does not support cd -P
echo -n
incorrect output for command -v
incorrect output for alias
POSIX-mode bash:
echo -n
incorrect output for command
> 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 s
> 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 nee
> 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 w
> Umm, could you explain why this is so?
I think it is reasonable to assume that "POSIX features" and "non-POSIX
features" translate to those which are and are not mandated by the
current POSIX standard.
Thus, shell scripts specifying `/bin/sh' as interpreter should only
use POSIX
> 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 overrid
> 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.
> 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
> 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]
> 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 [
> 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.
D
> 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;
> What if the user puts "tripwire" or some other nice English word in the
> path, not knowing this is also a command in Debian? It's really hard to
> account for any of these weird scenarios...
What if? I also wouldn't expect, nor want, to have Debian package scripts
trying to execute some random
> 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 'd
> 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 wh
> 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
> 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
> 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 Herbe
> 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
> 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
> 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 built
> 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 ext
> 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 PRO
> Ah. So we effectively require that ``/bin/sh should be a POSIX (SUSv3)
> shell supporting the "UP" extension, and a BSD echo.'' Along with other,
> as yet unknown, caveats. Strange that Linux "echo" is still considered
> to contravene POSIX.
So we should either make this explicit, and file bugs
> 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]
> 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"
> 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
> 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
> 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 support
> 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]
> 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 implem
> 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 con
> 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,
> The same should probably be done for every package which installs daemons
> which listen on a well known port.
Why don't we talk about solving the problem of not having a
mechanism to manage network services instead of trying to make
the Conflicts situation worse?
> Fair enough. As someone then (almost) suggested, have
> /usr/X11R6/include/X11/{pix,bit}maps both be symlinks to
> /usr/share/icons and keep all icons there.
This is nice, but aren't you implying that all {pix,bit}maps are
icons?
> 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
> 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.
> 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?"
> 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 serv
> Because as everyone knows the last 10% takes 90% of the work and often ends up
> hurting the other 90%.
Then it's being done wrong.
> The point is Debian needs to work for as many people as possible. We are
> doing
Yes, that's exactly the point.
> apt-get source qpopper
[...]
> dpkg -i qpop
> 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
> If you want to run two httpd's, popd's or mta's, you'll probably have to
> do more than the usual tweaking to the package setup anyway, so what is
> really the big deal of having to:
>
> 1. `apt-get source foo`
> 2. edit various files, mostly in debian/
> 3. add an epoch to the package versio
1 - 100 of 109 matches
Mail list logo
