At (time_t)1027974412 Wichert Akkerman wrote:
> For each virtual package we should document
>
> * a description of what it should be used for
> * a complete description of the interface packages should provide if
> that is relevant for that virtual package
Another potential documentation point
On Tue, Mar 06, 2001 at 12:01:05PM +0100, Richard Braakman wrote:
> I think the basic problem here is that the policy manual is using
> MUST and SHOULD (actually _must_ and _should_) in a different sense
> than anywhere else. This is hard to adjust to for someone used to
> reading RFCs.
>
> The u
On Tue, Mar 06, 2001 at 12:01:05PM +0100, Richard Braakman wrote:
> I think the basic problem here is that the policy manual is using
> MUST and SHOULD (actually _must_ and _should_) in a different sense
> than anywhere else.
Actually it's just the words `must' and `should', capitalisation and
ma
On Tue, Mar 06, 2001 at 04:53:24PM +1000, Anthony Towns wrote:
> Packages with RC bugs, packages violating policy requirements (musts)
> get pulled. That's what RC bugs, and MUSTs, are for. They don't have any
> other purpose; they're not there to give us a bigger or sharper stick
> for beating ina
On Tue, Mar 06, 2001 at 04:53:24PM +1000, Anthony Towns wrote:
>
> Packages with RC bugs, packages violating policy requirements (musts)
> get pulled. That's what RC bugs, and MUSTs, are for. They don't have any
> other purpose; they're not there to give us a bigger or sharper stick
> for beating
On Tue, Mar 06, 2001 at 12:07:20AM -0500, Ben Collins wrote:
> On Tue, Mar 06, 2001 at 10:24:41AM +1000, Anthony Towns wrote:
> > On Mon, Mar 05, 2001 at 09:01:23AM -0500, Ben Collins wrote:
> > > IMO, it should say "packages SHOULD change the docs to match the package
> > > setup", and "there MUST
* Brian May <[EMAIL PROTECTED]> [010305 22:20]:
> I would suggest that it would be better use of the maintainers time
> fixing problems.
It shouldn't be that tough; note whatever the --prefix etc options are
to the configure script if it has one, and make a note of this in
README.Debian. For those
> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
Ben> If the maintainer can't add "The docs reference paths that do
Ben> not exist on a Debian system" to README.Debian, then I would
Ben> think something is severely wrong with how the package is
Ben> maintained.
I would sugge
On Tue, Mar 06, 2001 at 10:24:41AM +1000, Anthony Towns wrote:
> On Mon, Mar 05, 2001 at 09:01:23AM -0500, Ben Collins wrote:
> > IMO, it should say "packages SHOULD change the docs to match the package
> > setup", and "there MUST be a disclaimer when docs do not match the
> > package", and "the di
On Mon, Mar 05, 2001 at 09:01:23AM -0500, Ben Collins wrote:
> IMO, it should say "packages SHOULD change the docs to match the package
> setup", and "there MUST be a disclaimer when docs do not match the
> package", and "the disclaimer SHOULD be in the upstream doc itself, or in
> a the README.Deb
On Mon, Mar 05, 2001 at 08:07:56AM -0500, Sam Hartman wrote:
>
> As such, I would not like to see a MUST added to policy for updating upstream
> docs.
>
I think it should atleast say "Some of the locations and features depend
on how the program was compiled and installed". This is what it say
> "Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes:
>> I think that all documentation must reflect the Debian
>> locations of configuration and other files, and that manpages
>> and the like should be altered as necessary to achieve this.
>> =20 Comments?
Henri
>>"Oliver" == Oliver Elphick writes:
Oliver> I think that all documentation must reflect the Debian
Oliver> locations of configuration and other files, and that manpages
Oliver> and the like should be altered as necessary to achieve this.
Oliver> Comments?
Indeed, incorrect document
On Fri, Mar 02, 2001 at 11:34:09PM -0300, Nicolás Lichtmaier wrote:
> > That would be a reason *not* to put it in policy, at least until we
> > consider the reasons for such a refusal. Policy is supposed to
> > encode the things we do agree on.
>
> That's not true, and it never was. Policy chan
> That would be a reason *not* to put it in policy, at least until we
> consider the reasons for such a refusal. Policy is supposed to
> encode the things we do agree on.
That's not true, and it never was. Policy changes often leaves existing
packages in non-compliance. And that's good.
As I s
On 02-Mar-01, 11:25 (CST), Richard Braakman <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 02, 2001 at 10:43:21AM -0300, Henrique M Holschuh wrote:
> > I have doubts we need to add such to policy... Maybe mentioning "make sure
> > you update the location of files in the documentation you are packaging"
On Fri, 02 Mar 2001, Richard Braakman wrote:
> On Fri, Mar 02, 2001 at 10:43:21AM -0300, Henrique M Holschuh wrote:
> > I have doubts we need to add such to policy... Maybe mentioning "make sure
> > you update the location of files in the documentation you are packaging" in
> > the packaging-guide
On Fri, Mar 02, 2001 at 10:43:21AM -0300, Henrique M Holschuh wrote:
> I wonder if anyone ever refused doing such a change?
That would be a reason *not* to put it in policy, at least until we
consider the reasons for such a refusal. Policy is supposed to
encode the things we do agree on.
> I ha
Previously Oliver Elphick wrote:
> I have in the past seen people argue that the upstream stuff should
> be left alone.
Many things are argued, but not all are correct. If you follow that
reasoning we would all be DJB-clones..
Wichert.
--
___
Anthony Towns wrote:
>
>--Dxnq1zWXvFF0Q93v
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Fri, Mar 02, 2001 at 12:55:01PM +, Oliver Elphick wrote:
>> Configuration file locations are oftenn changed for
Wichert Akkerman wrote:
>Previously Oliver Elphick wrote:
>> I think that all documentation must reflect the Debian locations of
>> configuration and other files, and that manpages and the like should be
>> altered as necessary to achieve this.
>
>I would consider this a normal task for
On Fri, 02 Mar 2001, Oliver Elphick wrote:
> Configuration file locations are oftenn changed for Debian. However the
> manual pages still refer to the upstream locations. This makes it very
> difficult to find out where to make changes, particularly for new users.
AFAIK what you describe is a bu
Previously Oliver Elphick wrote:
> I think that all documentation must reflect the Debian locations of
> configuration and other files, and that manpages and the like should be
> altered as necessary to achieve this.
I would consider this a normal task for a maintainer and is too obvious
to be in
On Fri, Mar 02, 2001 at 12:55:01PM +, Oliver Elphick wrote:
> Configuration file locations are oftenn changed for Debian. However the
> manual pages still refer to the upstream locations. This makes it very
> difficult to find out where to make changes, particularly for new users.
Uh, so wha
I should like to suggest an alteration to policy in respect of package
documentation.
Configuration file locations are oftenn changed for Debian. However the
manual pages still refer to the upstream locations. This makes it very
difficult to find out where to make changes, particularly for new
> On Tue, Apr 07, 1998 at 07:05:33PM +0100, Ian Jackson wrote:
> > I propose the following extra requirement for non-free and contrib
> > packages:
> >
> > A package which is non-free must contain a file
> > /usr/doc//README.non-free (or one of its dependencies must
> > contain a relevant such fil
[I wonder at which stage this proposal is at the moment]
On Tue, Apr 07, 1998 at 07:05:33PM +0100, Ian Jackson wrote:
> I propose the following extra requirement for non-free and contrib
> packages:
>
> A package which is non-free must contain a file
> /usr/doc//README.non-free (or one of its dep
Manoj Srivastava wrote:
> Tracking down all the people involved in that is way too much
> work for me; I would just continue to maintain the package for
> myself, if the "track down and implore author" policy were made
> madatory.
>
> A free software fanatic would probably say that
Hi,
>>"Alex" == <[EMAIL PROTECTED]> writes:
>> I disagree. A package's placement in non-free should be a last
>> resort. Making sorting out the copyright a requirement for
>> inclusion in non-free will encourage efforts to fix the problem.
Alex> ... and be the way to ban the packages from bei
> > [Ian:]
> > > A package which is non-free must contain a file
> > > /usr/doc//README.non-free (or one of its dependencies must
> > > contain a relevant such file). This file must contain either:
> > >
> > > 1. A copy of an electronic mail message received by the package
> > > maintainer from t
Branden Robinson writes ("Re: Non-free package documentation requirement"):
> Uh, can we have some exception classes to this?
>
> For instance, xtrs is in contrib because it requires the ROM images from
> some very old, long dead computers. Those images were copyrighted
Alex Yukhimets writes ("Re: Non-free package documentation requirement"):
...
> [Ian:]
> > A package which is non-free must contain a file
> > /usr/doc//README.non-free (or one of its dependencies must
> > contain a relevant such file). This file must contain e
Uh, can we have some exception classes to this?
For instance, xtrs is in contrib because it requires the ROM images from
some very old, long dead computers. Those images were copyrighted by
Tandy/Radio Shack and/or Microsoft. Their current legal status may be
difficult to determine, and should t
On Tue, 7 Apr 1998, Shaleh wrote:
> Count me 100% in favor. One question -- what about giflib where the
> copyright is obvious and will not change. Can this be noted rather than
> wasting our time e-mailing them?
I expect we can/should probably draft a standard disclaimer similar to:
--- snip
Count me 100% in favor. One question -- what about giflib where the
copyright is obvious and will not change. Can this be noted rather than
wasting our time e-mailing them?
--
---
How can you see, when your mind is not open?
How can you think, when yo
> I propose the following extra requirement for non-free and contrib
> packages:
Hi.
While I understand the reason for this requirement to appear,
I would suggest to either make it not "requirement" but "strong
encouragement" to the maintainer or alter this requirement
in the following way:
>
I propose the following extra requirement for non-free and contrib
packages:
A package which is non-free must contain a file
/usr/doc//README.non-free (or one of its dependencies must
contain a relevant such file). This file must contain either:
1. A copy of an electronic mail message received b
37 matches
Mail list logo
