Hi,
I also think this "should" might as well be changed into a "must" these
days, because the ambiguity is allowing corner cases - I recently heard that
mcollective doesn't support a "restart" action, rather it does "stop" then
"start" when you tell it to restart something. Arguably this is simply
On Sat, Jul 05, 2008 at 04:26:25PM -0700, Russ Allbery wrote:
> > Okay, given that I see no rationale for the sentence "Mailboxes must be
> > writable by group mail.", I'm reassigning this to debian-policy.
>
> Here is a proposed change to loosen this requirement. Please comment.
> One concern th
On Tue, Mar 18, 2008 at 11:53:29AM +0100, Raphael Hertzog wrote:
> On Tue, 18 Mar 2008, Josip Rodin wrote:
> > Or they don't use root at all for the MDA, instead setuid'ing to the user
> > itself. See also #405584.
>
> If you didn't had to setuid to the user, y
On Tue, Mar 18, 2008 at 09:50:09AM -0700, Russ Allbery wrote:
> Josip Rodin <[EMAIL PROTECTED]> writes:
> > On Mon, Mar 17, 2008 at 09:56:52PM -0700, Russ Allbery wrote:
>
> >> I don't know what the original Debian rationale was, but the
> >> tradition
On Mon, Mar 17, 2008 at 09:56:52PM -0700, Russ Allbery wrote:
> Josip Rodin <[EMAIL PROTECTED]> writes:
> > Okay, given that I see no rationale for the sentence "Mailboxes must be
> > writable by group mail.", I'm reassigning this to debian-policy.
> >
&
reopen 470994
reassign 470994 debian-policy
thanks
On Sat, Mar 15, 2008 at 08:57:13AM +0100, Marc Haber wrote:
> On Sat, Mar 15, 2008 at 01:27:25AM +0100, Josip Rodin wrote:
> > The package's /etc/exim4/conf.d/transport/30_exim4-config_mail_spool
> > says:
> >
>
On Sun, Dec 03, 2006 at 05:49:23PM +, Enrico Zini wrote:
> enrico> Just when I wanted to split Maintainer fields my commas, I
> stumble on Maintainer: Adam C. Powell, IV <[EMAIL PROTECTED]>
There is no reason to split Maintainer fields, because they should be
nothing to split.
> Thi
On Wed, Apr 26, 2006 at 09:46:50AM -0500, Manoj Srivastava wrote:
[Subject: Closing out ancient, fixed bugs]
> Versions: 3.7.0.0
This may be an ancient bug, but it's not a fixed bug. It is a matter over
which we have not found an agreement, and Policy 3.7 didn't do anything
particular about it AFA
On Thu, Jun 08, 2006 at 02:48:34PM +0200, Bill Allombert wrote:
> Homepage: http://some-project.some-place.org/
>
> Please make sure that this line matches the regular
> expression `/^ Homepage: [^ ]*$/', as this allows
> `packages.debian.org' to parse it correctly.
Bac
On Tue, Dec 30, 2003 at 04:44:50AM +0800, Dan Jacobson wrote:
> Package: debian-policy
> Version: 3.6.1.0
> Severity: wishlist
>
> Debian should no longer be like some mere arcade kiddie game machine,
> where if you don't like the games staring when you deposit your coin,
> then sorry.
I'm not pa
On Sun, Dec 21, 2003 at 06:01:30PM -0700, Bob Proulx wrote:
> One of the examples listed in B.1 is not correct and does not work.
> To view the copyright file for a package you could use this command:
>
> - dpkg --fsys-tarfile filename.deb | tar xof usr/share/doc/\*copyright
> | less
> +
On Mon, Dec 08, 2003 at 11:50:52AM -0500, Matt Zimmerman wrote:
> > Epochs are more inelegant because they never go away, and rather have a
> > tendency of needing increases, which has a tendency of getting more
> > confusing;
> > the ^(0\.)+ parts, on the other hand, disappear when the program au
[half-reposted]
On Sun, Nov 30, 2003 at 04:32:09PM +1100, Herbert Xu wrote:
> However, epochs are designed so that they only need to be shown where
> it is necessary to establish the aboslute order between two arbitrary
> version numbers.
Hiding epochs actually has adverse effects (I've seen sever
On Thu, Dec 04, 2003 at 12:31:11AM +0100, Bill Allombert wrote:
> > Section 3.6.1.0 of policy recommends registering HTML documents with the
> > menu package. AFAIK this practice has been supersceded by doc-base.
> > Although oddly, I see no mentions of doc-base in policy.
>
> Document menu entry
[reposting to proper forum]
On Sat, Nov 29, 2003 at 04:51:47PM +1100, Herbert Xu wrote:
> >> > I would suggest using 0.MMDD to avoid using epoch when upstream
> >> > finally decides to use version 1.0 instead.
> >>
> >> What's wrong with using an epoch?
> >
> > Most people would prefer not us
On Wed, Nov 26, 2003 at 09:49:38PM -0500, Peter S Galbraith wrote:
> : To prevent having to use epochs for every new upstream version, the
> : version number should be changed to the following format in such
> : cases: "19960501", "19961224". It is up to the maintainer whether
> :
On Wed, Nov 12, 2003 at 07:10:26PM +0100, Bill Allombert wrote:
> Section 5.6 lists valid control fields, but omit Build-Depends et al,
> which are mentionned in 7.6
>
> Is it an oversight ?
We could add another section with a link to 7.6, analogous to 5.6.9
"Package interrelationship fields", bu
On Fri, Nov 07, 2003 at 10:42:46PM -0500, Branden Robinson wrote:
> > Joy proposed to put such information in debian/control instead.
> >
> > The idea of a new file was to ease parsing, but since it is read by
> > dpkg-buildpackage it should be OK.
>
> This prevents people from using tricks like
On Sat, Nov 08, 2003 at 03:42:49AM -0600, Luca - De Whiskey's - De Vitis wrote:
> If you put a tag you'll patch the problem, show restricted prospecitves,
> and add more burden to the same component, while we need a more complex
> structure, flatten the resonsibilities of each component and eventua
On Fri, Nov 07, 2003 at 08:41:13AM -0600, Luca - De Whiskey's - De Vitis wrote:
> > Yeah. If someone really thinks of changing the control file interface as
> > well, where's the guarantee that debian/ will be in the same place, and
> > that debian/interface won't stand out? I think that putting th
On Fri, Nov 07, 2003 at 01:25:37PM -0600, Luca - De Whiskey's - De Vitis wrote:
> > Yeah. If someone really thinks of changing the control file interface as
> > well, where's the guarantee that debian/ will be in the same place, and
> > that debian/interface won't stand out? I think that putting th
On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote:
> > > So, why not a mix of these two? why don't we attach the concept of
> > > interface
> > > to the entire source package?
> > >
> > > debian/interface could be a file in which we describe the interface
> > > implemented by each co
On Tue, Nov 04, 2003 at 02:04:27AM +, Colin Watson wrote:
> It's newer and shinier, so it must be better, right?
>
> If we're adding optional features, doing so in a way that doesn't
> confuse people into believing that all packages need to use them would
> definitely be a good thing, I think.
On Tue, Nov 04, 2003 at 12:32:47AM +0100, Bill Allombert wrote:
> > > (What I dislike is a "format version", mandatory conversion of all
> > > packages to the new format in the long run, and all that).
> >
> > What mandatory conversion to the new format in the long run?
>
> As I see it: currently
On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
> Packages which do not benefit from a split build-arch / build-indep
> (and there are certainly a lot of packages which do not benefit)
> should continue to be allowed not to have such targets, without people
> or policy saying they ar
On Mon, Nov 03, 2003 at 06:32:55PM +0100, Bill Allombert wrote:
> On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
> > What are the real benefits from having build-arch and build-indep?
> > Are there really so many packages which would benefit from having them?
> >
> > (Remember "deb
On Mon, Nov 03, 2003 at 01:04:38PM +, Julian Gilbey wrote:
> > > 3.1) Provide an easy and reliable way to tell if the optional targets
> > > are implemented.
> >
> > And once that's there, clarify Policy to say what dpkg-buildpackage et al
> > will do: if optional targets are missing, do the
On Mon, Nov 03, 2003 at 12:36:15PM +0100, Santiago Vila wrote:
> I object to making the packaging system more complex without a real gain.
>
> We should better document what "Build-Depends-Indep:" really mean:
> That which autobuilders do not need to install to produce Architecture: any
> packages
On Mon, Nov 03, 2003 at 11:57:51AM +0100, Bill Allombert wrote:
> Some packages generate the control file at build time (e.g. from a
> control.in). We need to access the file before debian/rules is used,
> and debian/control might not exist yet.
AFAIK they all have the source section, they only a
On Mon, Nov 03, 2003 at 06:49:41PM +0900, YAMASHITA Junji wrote:
> Package: debian-policy
> Version: 3.6.1.0
> Severity: wishlist
>
> I noticed that desktop-base package adds local diversion, reported as
> Bug#218091. I supposed that this isn't a right thing and is a serious bug.
>
> But I can't
reassign 218879 debiandoc-sgml
thanks
On Mon, Nov 03, 2003 at 07:50:33AM +, [EMAIL PROTECTED] wrote:
> Package: debian-policy
> Version: 3.6.1.0
>
> In Package debian-policy_3-1.6.1.0_all.deb you should regenerate files
> policy.p[s|df] from p
On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> 3.1) Provide an easy and reliable way to tell if the optional targets
> are implemented.
And once that's there, clarify Policy to say what dpkg-buildpackage et al
will do: if optional targets are missing, do the old thing. If the o
Hi,
You wrote:
> It would be nice to have Debian policy available as info packages for
> emacs. The best way to do this, I suppose is to have a seperate
> package...
% du -ksh policy.info*
12K policy.info
300Kpolicy.info-1
16K policy.info-2
I'm not sure if it's worth it. Can you gen
On Sun, Nov 02, 2003 at 11:17:10AM +, Mark Brown wrote:
> > Since when does the package libc6-dev depend on linux-kernel-headers? Is
> > this dependes really necessary?
>
> There have always been some kernel headers in libc6-dev, they've just
> been split out into a separate package now. Seve
On Sun, Oct 26, 2003 at 01:53:26PM +0100, Bernhard R. Link wrote:
> Policy 5.6.11 describes the upstream version part as:
> | if there is no epoch then colons are not allowed.
~
> Thus I suggest 5.6.11 to be changed so that colons are no longer al
On Wed, Oct 29, 2003 at 04:04:35AM +0100, Henning Makholm wrote:
> debian/rules should be portable enough to work with any implementation
> of make [1]. That's the interface. If I have an implmentation that I know
> supports include files, I should be able to ask *my* implementation of
> make to in
On Tue, Oct 21, 2003 at 05:01:21PM -0500, Manoj Srivastava wrote:
> the fact is that this has been accepted practice as long as there has
> been a rules file, and has been documented as being a Makefile for some
> time now.
>
> Given the lack of a compelling technical reason to change,
>
On Tue, Oct 21, 2003 at 05:13:14PM -0500, Manoj Srivastava wrote:
> I have made a few (including ./debian/rules in an superset
> debugging makefile, passing variables in MAKEFLAGS, using -j, -n, -p
> and other make arguments to arrive at similar invocations, using
> VPATH's et all to tempo
On Tue, Oct 21, 2003 at 05:03:53PM -0500, Manoj Srivastava wrote:
> >> If you do not stick to the documented interfaces, you lose the
> >> ability in my eyes to express outrage when the interfaces you use
> >> change.
>
> > Except one important difference -- in this case, NOTHING CHANGES in
> > th
On Mon, Oct 20, 2003 at 01:06:30AM +0200, Bill Allombert wrote:
> Summary of the auction so far:
>
> Steve bet on Manoj and Josip on Wichert.
>
> Deuce.
We might be more successful in resolving the issue if some people stopped
thinking of it as an ad hominem flamewar. :p
> > The interface to th
On Sun, Oct 19, 2003 at 03:58:19PM -0500, Steve Greenland wrote:
> I've yet to see a technical argument for allowing debian/rules to be a
> non-makefile.
I've yet to see a technical argument for disallowing debian/rules from being
a non-makefile.
See, those two statements make the same amount of
On Sun, Oct 19, 2003 at 11:50:41AM -0500, Steve Greenland wrote:
> > But it's a historic injustice,
>
> Help! Help! I'm being repressed!
> The Man is keeping me down!
> Up with perl, down with make!
> Power to the people!
We share an enthusiasm for overloaded phrases, I see :)
but a small verbal
On Sun, Oct 19, 2003 at 12:18:51PM +0200, Bill Allombert wrote:
> > this-and-that function of Make" (so far I remember only two of those, when
> > the DEB_BUILD_OPTIONS env. variable was added and when testing for existence
> > of build-arch was added).
>
> ... which was a fiasco. Doogie finally i
On Sat, Oct 18, 2003 at 04:37:45PM -0500, Manoj Srivastava wrote:
> > 88029
>
> yeah well. That is not all the dfiscussion there was on it. In
> March 2001, we had more than those comments on it:
Nah, I saw that one as well, and I'm fairly sure I answered it back then.
If not, please let m
On Sun, Oct 05, 2003 at 06:18:18AM -0500, Debian Bug Tracking System wrote:
> > owner 185943 !
> Bug#185943: [ACCEPTED] new virtual package: inetd-superserver
> Owner recorded as Martin Godisch <[EMAIL PROTECTED]>.
>
> > owner 208010 !
> Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
> Owne
On Fri, Oct 03, 2003 at 05:19:59PM +0200, Bill Allombert wrote:
> > Since libqt3-mt-dev depends on libqt3-headers (= 3:3.2.1-5)
>
> Maybe you can weaken the dependency to libqt3-headers (= 3:3.2.1) ?
> The would lessen the impact of the problem.
Actually that wouldn't work at all, because I don't
On Tue, Sep 30, 2003 at 07:33:09PM -0500, Manoj Srivastava wrote:
> >> What this proposal needs is not seconds, but analysis. If someone
> >> produces a list of all the changes that were made, with a
> >> preliminary analysis of the impact on Debian packages, then we can
> >> go on with this. Or e
On Mon, Sep 29, 2003 at 11:01:02AM +0200, Thomas -Balu- Walter wrote:
> > Investigate the purpose of this library and you'll probably come to your
> > own conclusion.
>
> I finally found the solution while searching for exemptions:
>
> "A common example are the so-called "plug-ins", internal shar
On Sun, Sep 28, 2003 at 09:57:55PM +0200, Bill Allombert wrote:
> I would like to mention that according to policy 12.3:
>
> Packages must not require the existence of any files in
> `/usr/share/doc/' in order to function [1]. Any files that are
> referenced by programs but are als
On Sun, Sep 28, 2003 at 02:52:55PM +0200, Stefano Zacchiroli wrote:
> > I would recommend that we have policy suggest ("may") the latter solution,
> > and see how it goes from there. Any objections?
>
> You mean "may" add the symlink, right? If so it will be a good solution
> also in my opinion. B
On Tue, Sep 23, 2003 at 06:33:44PM +0200, Tobias Burnus wrote:
> How about requiring [FHS version 2.2] instead? Without looking carefully
> at the changes, I think even Woody is complient.
Do look carefully at the changes, it would be foolish to change Policy
otherwise.
--
2. That which cau
On Thu, Sep 18, 2003 at 11:56:31AM +0200, Thomas -Balu- Walter wrote:
> * Flush separate lib and lib-dev packages.
>
> So is this a wrong packaged camserv or is there a way around the policy
> rule from above (which would make packaging easier, since I'd only have
> to create one .deb)?
W
On Thu, Sep 18, 2003 at 04:01:26AM -0500, Manoj Srivastava wrote:
> >> Pristine sources are already a desired, but not required,
> >> characteristic. There are enough brain dead upstream packaging
> >> practices that we can not mandate pristine sources.
>
> > Dont go blaming "upstream" for debians
On Wed, Sep 24, 2003 at 03:51:31PM +0200, Stefano Zacchiroli wrote:
> > We had another discussion on where to put the contents of -doc packages
> > separate from the bug report in which a degree of consensus was reached,
> > but I can't seem to find it now. I'll keep searching...
>
> Thanks, I'm i
On Wed, Sep 24, 2003 at 01:45:23PM +0200, Stefano Zacchiroli wrote:
> I've read the bug report and I'm interested to know if this bug is
> being considered by the policy people or not. I've also read a bit of
> the debian-policy archives but it seems that the issue hasn't been
> resolved.
We had
On Mon, Sep 22, 2003 at 01:23:03PM +0200, J.H.M. Dassen (Ray) wrote:
> Package: debian-policy
> Version: 3.6.1.0
> Severity: normal
> Tags: patch
>
> diff -r -u debian-policy-3.6.1.0.orig/mime-policy.sgml
> debian-policy-3.6.1.0/mime-policy.sgml
> --- debian-policy-3.6.1.0.orig/mime-policy.sgml
On Wed, Sep 03, 2003 at 01:55:45AM +0200, Denis Barbier wrote:
> > This is a copout. If the field is not supposed to have non
> > ascii characters (since the tool chain can not yet handle them), then
> > policy should not be specifying the encoding of these illegal
> > characters.
>
> Wro
On Tue, Sep 02, 2003 at 08:42:00PM +0200, Stefan Gybas wrote:
> > And how do you suppose this consensus thing works if you can't get a
> > consensus over the said policy changes? I sense a grave misunderstanding...
>
> It doesn't work, you'll never get a consensus with over 1000
> developers. That
On Tue, Sep 02, 2003 at 06:43:28PM +0200, Martin Godisch wrote:
> > Your proposal says "the control fields". Description is just one, what
> > about all the others? (If it was your intent to only do this for
> > descriptions, why doesn't the proposal say so?)
>
> I think there should be one encodi
On Tue, Sep 02, 2003 at 11:26:23AM -0500, Manoj Srivastava wrote:
> Remember, the policy mailing list members are not DPL
> delegates, and have never been delegates.
Even if we were, it would still be wrong to exercise the power to do massive
changes without massive consensus.
(The whole d
On Tue, Sep 02, 2003 at 07:36:11PM +0200, Stefan Gybas wrote:
> I only wanted to show that it has been impossible the get major Policy
> changes accepted in the past 4 years.
As opposed to the six years before that, when major policy changes happened
all the time? :)
> Improving the init scripts
On Tue, Sep 02, 2003 at 05:48:27AM +0200, Martin Godisch wrote:
> > > Anyway I fail to see which problems arise with this proposal, could
> > > someone enlighten me?
> >
> > It's too broad. Has anyone tested if the packaging system correctly
> > processes double-byte information everywhere?
>
> I
On Tue, Sep 02, 2003 at 02:37:16PM +0200, Andreas Metzler wrote:
> > It will display incorrectly on the vast majority of workstations. Few
> > people are using UTF-8 terminals.
>
> I won't contradict you, but almost the same thing applies to
> debian/changelog (dpkg-parsechangelog), nevertheless i
On Tue, Sep 02, 2003 at 11:10:17AM +0200, Stefan Gybas wrote:
> Yes, these examples are long in the past, but I also think that the FHS
> transition over 4 years ago has been the last major Policy change that
> affected more than just a few packages.
Sorry, I lost you there. Is that to make us b
On Mon, Sep 01, 2003 at 11:29:38PM +0200, Denis Barbier wrote:
> > > Right, it mostly means that their name contains non-ASCII letters.
> >
> > And that they are unwilling to conform, unlike everyone else. Issues should
> > be fixed (e.g. by patching the packaging system and whatever else), not
>
On Mon, Sep 01, 2003 at 10:37:32PM +0200, Denis Barbier wrote:
> > > > > Some control files contain non-ASCII characters, there is no reason
> > > > > not
> > > > > to mandate UTF-8 instead of random encodings.
> > >
> > > Either you choose to mandate UTF-8, or you choose to forbid any encoding
>
On Mon, Sep 01, 2003 at 09:15:02PM +0200, Mike Hommey wrote:
> > > Some control files contain non-ASCII characters, there is no reason not
> > > to mandate UTF-8 instead of random encodings.
>
> Either you choose to mandate UTF-8, or you choose to forbid any encoding
> other than ASCII7.
The latt
On Mon, Sep 01, 2003 at 12:48:58PM +0200, Martin Godisch wrote:
> > > + Otherwise, the init script should print an error message and return
> > > + one of the following non-zero exit status codes.
> >
> > Rationale for the whole elaborate list,
>
> Following closely the wording of the LSB, as
On Mon, Sep 01, 2003 at 10:58:50AM +0200, Martin Godisch wrote:
> --- debian-policy-3.6.1.0.orig/policy.sgml2003-08-19 14:32:23.0
> +0200
> +++ debian-policy-3.6.1.0/policy.sgml 2003-09-01 10:52:12.0 +0200
> + status
> + print the current status of the servi
On Tue, Aug 26, 2003 at 09:53:44PM +0200, Frédéric Bothamy wrote:
> Here is a very small diff fixing a typo against current CVS.
>
> --- debian-policy.sgml.orig Tue Aug 26 21:44:10 2003
> +++ debian-policy.sgmlTue Aug 26 21:44:28 2003
> @@ -7207,7 +7207,7 @@
> - currently recog
On Tue, Aug 26, 2003 at 09:14:03PM +0200, Jens Seidel wrote:
> I think the handling of empty strings in version numbers is wrong
> (tested with dpkg 1.10.10). I experienced with two packages
> pkg_1.1beta3-1_i386.deb and pkg_1.1-1_i386.deb. It seems that 1.1beta3-1
> is newer than version 1.1-1. I
On Tue, Aug 26, 2003 at 02:44:00AM +1000, Anthony Towns wrote:
> > I'd rather if we dropped all such transitional issues from the Policy
> > manual. They're just bother and don't really have to be here to be mandated
> > by the project (examples abound -- libc6-migration, fhs migration, C++ 3
> > t
On Tue, Aug 26, 2003 at 06:54:31PM +1000, Anthony Towns wrote:
> But doing any of that requires a document that's willing to cover all
> the things we're trying to achieve. Having many documents doesn't work,
> because packagers coming to Debian need to be able to find *everything*
> that affects t
On Mon, Aug 25, 2003 at 10:41:46AM +0200, Goswin Brederlow wrote:
> Package: debian-policy
> Version: 3.6.1.0
> Severity: normal
>
> again someone asks for what to do about gcc 2.95->3.2 transition and
> the right place would be to point to the debian-policy package just as
> with the libc6 transi
epted. We should add it as "may", send mails or wishlist bugs
for all packages that don't comply, and later upgrade it to "should".
> ======
> * #65764: changelog shouldn't be in the copyright fi
reopen 193748
thanks
On Sun, Aug 03, 2003 at 12:18:08PM -0500, Debian Bug Tracking System wrote:
> The new rewording of policy seems to have gotten rid of the
> offending recommendation; so this report can now be closed. Indeed, I
> can't find the string varargs anywhere in current polic
On Thu, Jul 31, 2003 at 04:51:29PM -0500, Manoj Srivastava wrote:
> > No, I mean that a complete consistency in the set of 10K packages is
> > practically impossible to achieve, let alone sustain. And then
> > there's always situations where it seems wrong to demote all
> > non-default alternatives
On Mon, Jul 21, 2003 at 01:54:59PM +0200, Santiago Vila wrote:
> > > I second the clarifying paragraph. I object to changing to "should".
> > > We must fix the wrong priorities once and forever, and keep them sane
> > > sane from release to release. If the *current* ftpmasters have not
> > > achiev
On Mon, Jul 21, 2003 at 01:25:35PM +0200, Santiago Vila wrote:
> I second the clarifying paragraph. I object to changing to "should".
> We must fix the wrong priorities once and forever, and keep them sane
> sane from release to release. If the *current* ftpmasters have not
> achieved this goal yet
On Fri, Jun 06, 2003 at 01:52:58PM +0100, Colin Watson wrote:
[...]
I propose this patch:
--- policy.sgml~2003-07-21 12:17:53.0 +0200
+++ policy.sgml 2003-07-21 12:31:13.0 +0200
@@ -779,11 +779,24 @@
- Packages must not depend on packages with lo
On Sun, Mar 23, 2003 at 07:21:41AM +0100, Martin Godisch wrote:
> Hence, I'm proposing a new virtual package name "internet-server" (or
> something like that).
On my relatively recent sid system:
% apt-cache showpkg inetd-superserver
Package: inetd-superserver
Versions:
Reverse Depends:
noffle
On Fri, Jul 18, 2003 at 01:18:20AM +0200, Bill Allombert wrote:
> > I see no point in including N bloody kilobytes of GFDL in the texinfo and
> > info packages' copyright files when the copyright is very much accessible
> > within the packages' info documentation, to which it only applies after all
On Sat, Jul 12, 2003 at 12:25:50AM -0400, Joey Hess wrote:
> > I believe exim4 should be the default mailer by the time sarge is
> > released, at least if its maintainers believe it is stable enough (I'm
> > now using it myself on my server, and I believe that it is).
>
> Has there been any prog
On Thu, Jul 10, 2003 at 06:21:42PM +0200, Christian Perrier wrote:
> Well, I of course second this proposal, just being tracking down
> packages who do not use debconf
Speaking of which, I object to the proposal to go from "may" to "must".
"should" needs to go inbetween.
--
2. That whic
On Wed, Jul 09, 2003 at 07:07:01PM -0500, Manoj Srivastava wrote:
> >> >> * Could no longer find the misspelling "seciton", thus this must
> >> >> have
> >> >> been fixed in a previous change in the manual. closes:
> >> >> Bug#193903
> >>
> >> > Tsk, bad Manoj (or whoever). If you didn't make a
On Wed, Jul 09, 2003 at 04:46:14PM -0500, Manoj Srivastava wrote:
> >> * Could no longer find the misspelling "seciton", thus this must
> >> have
> >> been fixed in a previous change in the manual. closes: Bug#193903
>
> > Tsk, bad Manoj (or whoever). If you didn't make a change, there
> > sho
On Wed, Jul 09, 2003 at 01:23:14PM -0700, Chris Waters wrote:
> > * Could no longer find the misspelling "seciton", thus this must have
> >been fixed in a previous change in the manual.closes: Bug#193903
>
> Tsk, bad Manoj (or whoever). If you didn't make a change, there
> shouldn't
On Tue, Jul 08, 2003 at 02:13:48PM +0200, Thomas Hood wrote:
> Package: debian-policy
> Version: 3.5.10.0
> Severity: minor
>
> Sometimes one needs to install a file in a run-parts or other "parts"
> directory that will be processed first or last. Often the other
> files in the directory are name
On Thu, Jul 03, 2003 at 12:04:20PM +0200, Michele Alessandrini wrote:
> in debian policy they are called, 2 or 3 times, "upstream authors", like
> if maintainers (largely mentioned) were the "main" authors.
Actually, no, no harm is meant by mentioning Debian maintainers more than
upstream maintain
On Thu, Jun 12, 2003 at 01:20:23PM +0200, Bill Allombert wrote:
> > CVSROOT:/cvs/debian-policy
> > Module name:debian-policy
> > Changes by: srivastaSat Jun 7 11:57:59 MDT 2003
> >
> > Modified files:
> > debian : changelog
> >
> > Log message:
> > Added Apps/E
On Thu, Jun 05, 2003 at 02:58:12PM -0400, Colin Walters wrote:
> The problem is that we have no way to know what encoding an individual
> Debian Changelog entry is in.
The problem is that my point entirely flew over your head. The point was,
as usual, that Policy is not designed to be a stick to b
On Thu, Jun 05, 2003 at 01:35:38PM +0200, Jérôme Marant wrote:
> I've seen some UTF-8-encoded debian/changelog files but I haven't
> seen anything mentioning it is allowed in Debian Policy.
>
> According to #174982, the proposal has been accepted but the bug
> is still open. When is this p
On Mon, Jun 02, 2003 at 04:47:01PM -0700, Chris Waters wrote:
> > Here the odds:
> > Sports: asciijump battleball billard-gl flyingfoobillard
> > (ski) (ball) (billard) (billard) (billard)
>
> > Simulation: achilles csmash flightgear gtkpool matrem xlife
> >
On Mon, Jun 02, 2003 at 10:57:07AM +0200, Daniel Stenberg wrote:
> I'm sorry, but isn't that just a bit stupid? The "WWW::" part in the perl
> name doesn't make the package depend or use libwww. It says the package is
> in the WWW category.
>
> I think that makes sense.
The "lib" part in the Debi
On Fri, May 30, 2003 at 04:05:20PM +0200, Philippe Batailler wrote:
> Here are some questions about the text of the policy, cvs version 1.119.
>
> L806:
> The package name is part of the file name of the
> .deb file and is included in the control field
> information.
On Sun, Jun 01, 2003 at 11:39:32AM +0200, Bill Allombert wrote:
> > > > Most of the programs there are simulations of the real world (though
> > > > achilles and matrem are a-life programs, and xlife seems to have been
> > > > thrown in some reason). There are slow simulations like atc from
> > > >
On Wed, May 28, 2003 at 10:41:16AM +0200, Bill Allombert wrote:
> > Most of the programs there are simulations of the real world (though
> > achilles and matrem are a-life programs, and xlife seems to have been
> > thrown in some reason). There are slow simulations like atc from
> > bsdgames, reali
On Sun, May 18, 2003 at 08:33:01PM +0200, Bill Allombert wrote:
> > > In light of recent changes, I suggest that policy should instead say:
> >
> > How about we just remove the whole section? The software now makes it clear
> > that the old stuff is a bug, and it's not like we need the Policy Manu
On Sun, May 18, 2003 at 03:41:45PM +0100, Colin Watson wrote:
> In light of recent changes, I suggest that policy should instead say:
How about we just remove the whole section? The software now makes it clear
that the old stuff is a bug, and it's not like we need the Policy Manual
to say "fix the
On Wed, Apr 30, 2003 at 04:28:13PM +0100, James Troup wrote:
> + with dlopen(). Packagers may wish to use the gcc
> ^^^
> + option -Wl,-z,defs when building a shared library.
>
> Couldn't this be a 'should'?
Wouldn't that be a reas
1 - 100 of 388 matches
Mail list logo
