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
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 packages have
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 remote
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
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 reports you want,
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 see
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
a field
* 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 program
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 so we
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
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 it.
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 to
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*.
Sam,
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 sense
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 changes
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
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 in
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 number is
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.
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 go to
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
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 particular,
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
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, you need
* 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 provider
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 paragraph
Anthony == Anthony Towns aj@azure.humbug.org.au 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
* 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 think
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 prefer it
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 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 second
31 matches
Mail list logo
