On Mon, 07 May 2001, Seth Arnold wrote:
> * Julian Gilbey <[EMAIL PROTECTED]> [010507 15:44]:
> > Most init.d scripts are expected to support all of start, stop,
> > etc. options. But there are a small number of scripts which are
> > obvious exceptions to this rule: restart, reboot, single, mount
On Mon, May 07, 2001 at 10:58:19PM +0200, Josip Rodin wrote:
> > > Yes, but if I amend the proposal like this, then it needs to be seconded
> > > all over again, doesn't it?
[...]
> Well, they don't invalidate it, but they change it from the one that the
> seconders seconded. How do I know their se
CVSROOT:/cvs/debian-policy
Module name:debian-policy
Changes by: jdg Mon May 7 17:21:13 PDT 2001
Modified files:
. : policy.sgml
debian : control
Removed files:
DebianDoc_SGML/Format: Text.pm
Log message:
* Done chapter 10 now
*
On Mon, May 07, 2001 at 04:23:47PM -0400, Joey Hess wrote:
> > My thought was that apt and dselect would be taught to recognise
> > Tasks: as a new type of dependency header, similar to Depends,
> > Recommends and Suggests, but with slightly different rules.
>
> If this were done, I would much pre
* Julian Gilbey <[EMAIL PROTECTED]> [010507 15:44]:
> Most init.d scripts are expected to support all of start, stop,
> etc. options. But there are a small number of scripts which are
> obvious exceptions to this rule: restart, reboot, single, mountall.sh
> and so on.
Julian, I'm inclined to thin
> "Anthony" == Anthony Towns writes:
Anthony> --HG+GLK89HZ1zG0kk Content-Type: text/plain;
Anthony> charset=us-ascii Content-Disposition: inline
Anthony> Content-Transfer-Encoding: quoted-printable
Anthony> On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin
Anthony> wr
On 07-May-2001 Julian Gilbey wrote:
> Most init.d scripts are expected to support all of start, stop,
> etc. options. But there are a small number of scripts which are
> obvious exceptions to this rule: restart, reboot, single, mountall.sh
> and so on.
>
> It would be really nice to have a parag
* Manoj Srivastava <[EMAIL PROTECTED]> [010507 13:53]:
> field; and using the standards version field as a reason ti file bugs
> is just plain wrong.
Is this working under the assumption that the release manager will drop
all packages "not recent enough" when freezing?
--
Earthlink: The #1 pro
On Sun, May 06, 2001 at 11:58:56PM +0300, Richard Braakman wrote:
> > Yes, but if I amend the proposal like this, then it needs to be seconded
> > all over again, doesn't it?
>
> I don't see why. You need two seconds to go from "proposal" to
> "amendment". To go from "amendment" to "accepted", y
Most init.d scripts are expected to support all of start, stop,
etc. options. But there are a small number of scripts which are
obvious exceptions to this rule: restart, reboot, single, mountall.sh
and so on.
It would be really nice to have a paragraph in policy distinguishing
between these cases
Julian Gilbey wrote:
> On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote:
> > err, does this break the use of tasks with apt-get later on? I've
> > found it very useful to do (for example) "apt-get install
> > task-x-window-system"
> > after getting a machine otherwise working (in parti
On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote:
> but you can't file 1060 RC bugs at the beginning of a freeze.
Why would you want to? File 1060 normal bugs before the freeze! (If
you must file 1060 bugs at all -- I hope that's not a habit of yours.)
If we want, we can adjust the se
On Sun, 06 May 2001, Anthony Towns wrote:
> So, here's the deal. We need to get a proper policy for tasks fairly soon.
I agree. The current task-* packages are mostly useless cruft for what they
were supposed to do, i.e. help users during the install.
> * There should only be a limited numb
On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote:
> err, does this break the use of tasks with apt-get later on? I've
> found it very useful to do (for example) "apt-get install
> task-x-window-system"
> after getting a machine otherwise working (in particular, that's the
> easy way to
On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote:
> err, does this break the use of tasks with apt-get later on? I've
> found it very useful to do (for example) "apt-get install
> task-x-window-system"
Possibly. task-x-window-system isn't really the greatest example of a task,
though.
>>"Adrian" == Adrian Bunk <[EMAIL PROTECTED]> writes:
Adrian> In the source package's `Standards-Version' control
Adrian> field, you must specify the most recent version number
Adrian> of this policy document with which your package
Adrian> complies. The current version
Please pay attention to my Mail-Copies-To and X-No-CC headers this time.
On Mon, May 07, 2001 at 02:20:54AM -0500, Sam TH wrote:
> Why did you not read the text you just quoted? I've never seen
> AbiWord work over remote X if the fonts weren't installed in *both*
> locations.
Sounds like a bug i
err, does this break the use of tasks with apt-get later on? I've
found it very useful to do (for example) "apt-get install task-x-window-system"
after getting a machine otherwise working (in particular, that's the
easy way to go to xf4 - install 2.2, then point to testing, then
apt-get install ta
On Mon, May 07, 2001 at 08:23:52PM +1000, Anthony Towns wrote:
> > Would it not be much easier for the task packages _themselves_ to
> > contain Task: fields, instead of the individual packages, which would
> > function like weak Recommends: fields:
>
> Not really. The code's already written to d
On Mon, May 07, 2001 at 08:51:00PM +1000, Anthony Towns wrote:
> On Mon, May 07, 2001 at 11:14:36AM +0100, Julian Gilbey wrote:
> > (3) Rewrite policy so that it's more comprehensible: its ordering
> > (merger of policy + packaging) is really hard work.
> > When I'm doing (3), I will make the c
On Sun, May 06, 2001 at 03:52:57PM -0500, Steve Greenland wrote:
> Uhh, when did that become a "must"? In 3.5.2 the first paragraph
> says
>
Probably during the policy/packaging merger. I intend at some point
to go through policy and fix all of these confusions. Furthermore, it
makes no sen
On Mon, May 07, 2001 at 03:08:38AM -0700, Seth Arnold wrote:
> * Sam TH <[EMAIL PROTECTED]> [010507 00:11]:
> > I've never seen AbiWord work over remote X if the fonts weren't
> > installed in *both* locations. Thus, AbiWord installs on a machine
> > without the fonts are *not useful* *at all*.
On Mon, May 07, 2001 at 11:14:36AM +0100, Julian Gilbey wrote:
> (3) Rewrite policy so that it's more comprehensible: its ordering
> (merger of policy + packaging) is really hard work.
> When I'm doing (3), I will make the changes to MUST and SHOULD which
> I've suggested, and will present it t
On Mon, May 07, 2001 at 03:08:38AM -0700, Seth Arnold wrote:
> However, if the AbiWord developers don't figure they will get around to
> fixing AbiWord any time soon, it sure would be a shame to keep AbiWord
> out of the distribution. Branden, would you have great compunction
> against making your
On Mon, May 07, 2001 at 11:06:41AM +0100, Julian Gilbey wrote:
> On Sun, May 06, 2001 at 04:42:19PM +1000, Anthony Towns wrote:
> > (Cc'ed to debian-boot)
> > tasksel in sid supports a "Task:" header for packages so we can be a
> > little more flexible than having every task- depend on everythig in
On Sun, May 06, 2001 at 04:47:07PM +1000, Anthony Towns wrote:
> (Later being after we work out a satisfactory way of specifying what "must"
> is meant to specify. Julian, I'd really appreciate it if you could propose
> something along those lines. But not in this thread...)
My current order of pr
On Sun, May 06, 2001 at 04:42:19PM +1000, Anthony Towns wrote:
> (Cc'ed to debian-boot)
>
> (First in porbably a series of policy changes needed for woody...)
>
> So, here's the deal. We need to get a proper policy for tasks fairly soon.
>
> tasksel in sid supports a "Task:" header for packages
* Sam TH <[EMAIL PROTECTED]> [010507 00:11]:
> I've never seen AbiWord work over remote X if the fonts weren't
> installed in *both* locations. Thus, AbiWord installs on a machine
> without the fonts are *not useful* *at all*.
Sam, please don't take offense at this: the way I see it, if
cannot
On Mon, May 07, 2001 at 11:19:57AM +0200, Adrian Bunk wrote:
> > Standards-Version you have, you still have to follow the FHS, you have
> > to use /usr/share/doc, and if you specify build-dependencies they have
> > to be correct.
> That means you can file RC bugs on all packages that don't follow t
On Mon, 7 May 2001, Anthony Towns wrote:
>...
> Standards-Versions aren't release critical. You can put it as
> "Standards-Version: 526.7.8.9.13-Foo.6" if you want. And no matter what
I will practice your suggestion and upload my packages with
"Standards-Version: 526.7.8.9.13-Foo.6".
> Standards
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
> List of packages with Standards-Version < 3.0
>
> <-- snip -->
> [...]
> Torsten Landschoff ([EMAIL PROTECTED]) gsfonts-other
> Torsten Landschoff ([EMAIL PROTECTED]) gsfonts
Guess I should really upload
On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote:
> Standards-Version < 3 :
> a not FHS compliant package is at most a "normal" bug
> Standards-Version >= 3:
> a not FHS compliant package is at most a "serious" bug
This is not correct. You can't change the severity of a bug by twiddling
Hi Adam!
You wrote:
> Actually, I already did a mass bug filing, on the usr/doc issue(did a grep on
> Contents-i386, which wasn't fully accurate(other archs, stale data(up to a
> week or so))). I have seen several of the bugs closed, probably more than
> half now. I need to do another scan, to
On Sun, 6 May 2001, Chris Waters wrote:
> > > Didn't we already have this discussion? The Standards-Version field
> > > is not a reliable indication of much of anything. I strongly object
>
> > Policy says:
>
> "Policy says" doesn't make the packages comply. And you can file all
> the bugs repo
Package: debian-policy
Version: 3.5.2.0
Severity: normal
Currently, sections 3.2.1 and 2.3.1 both give rules for package naming.
The latter is, however, more strict, and both use different terminology.
I suggest these two get synchronized and both be evenly strict.
I checked the version on the we
On Sun, May 06, 2001 at 10:55:14AM -0500, Branden Robinson wrote:
> On Sun, May 06, 2001 at 01:45:28AM -0500, Sam TH wrote:
> > Why should packages that require a particular font package for
> > operation (and indeed normally require that package to be installed on
> > the local system AND the remo
On Sun, 6 May 2001, Joey Hess wrote:
> Chris Waters wrote:
> > > - A change in the policy to remove the obsolete /usr/doc symlinks.
> >
> > This is supposed to happen once enough packages make the transition.
>
> No, it is supposed to happen one release _after_ a release in which all
> the package
On Sun, 6 May 2001, Chris Waters wrote:
> This is supposed to happen once enough packages make the transition.
> Now, if we're really down to 253 packages that use /usr/doc (with no
> symlink), then maybe it's time. But, unfortunately, that number, 253,
> measures *claimed* compliance, not actual
38 matches
Mail list logo
