On Thu, Aug 05, 1999 at 03:54:49PM +0100, Julian Gilbey wrote:
> > Wusses. :-)
>
> Huh? What does that mean?
Hasn't anybody ever seen Beavis and Butt-head?
--
G. Branden Robinson |I have a truly elegant proof of the
Debian GNU/Linux |above, but it is too l
On Thu, Aug 05, 1999 at 06:46:33PM +0200, Santiago Vila wrote:
> > > > Why does /var/mail have to exist before those packages are unpacked?
> > > Others have explained that this is probably not necessary for MTA's.
> > > However, it still seems necessary for MUA's. On a multi-user system,
> > > an
On Fri, Aug 06, 1999 at 12:58:17PM +1000, Anthony Towns wrote:
> MUAs that are currently executing will continue to work (the mail isn't
> getting moved or anything), by the time the MTA is configured, it'll
^^^
> work, and MTA's being executed sometime
Hi,
On Thu, Aug 05, 1999 at 12:55:46PM -0700, Chris Waters wrote:
> And hey, when it comes down to it, this is just a proposal. My
> *primary* goal is to give the tech committee something else to
> consider if Manoj *does* send his proposal to them! :-)
>
> I think that with the number of secon
> > The policy was immature.
> Shouldn't the decision be undone for now, then?
Why do you think that we couldn't make a decision now? And will those
reasons go away in the future?
> Well you're flying in the face of years of tradition if you say that. It's
> true it's not written down anywhere, but that doesn't mean you can just
> disregard it. Saying that is making a _large_ change to debian's goals.
The only drawback of your proposal are estethical. And it has concrete
b
> Nicolás> And this was handled pretty bad:
>
> Nicolás> 1) The update to the policy was obviously bad. It needed
> Nicolás>more discussion. Bad for the policy editors.
>
> What policy editors? There aren't any who have editorial
> power. And your comment is the reason why. Sorr
> > Having a prerm script for a long time is a bad thing? a price too
> > high? come on!
>
> I've currently got 2112 files in my /var/lib/dpkg/rules directory. It
> takes 10-50 seconds to read that directory if it's not already cached.
> The situation will only get worse as new packages are added
> While everybody involved in this discussions sits and goes in circles, the
> rest of the project is going to pass -policy by and just impliment policy
> as it states in the policy manual and by the time the people who get to
> decide actually decide, it'll be harder to implement due to the number
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> That you consider your proposal primary as an alternative to be
> considered by a committee that only steps in if the policy group
> fails is also something that worries me a lot.
Well, don't worry then, that's not primary, that's just a backup plan.
Laurent Martelli <[EMAIL PROTECTED]> writes:
> > "Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
> Chris> I think this is a great idea in concept. I think
> Chris> implementation may be a bit tricky, though, and I'd hate to
> Chris> have to rely on this as a short term solution. B
Package: debian-policy
Version: 3.0.1.0
Severity: wishlist
[Cc: me if you reply, I'm not on debian-policy.]
The current Policy manual says almost nothing about the README.Debian file. I
suggest to add a section 6.8 (in the "Documentation" chapter) or something
l
On Fri, Aug 06, 1999 at 11:59:38AM +0200, Stephane Bortzmeyer wrote:
> The current Policy manual says almost nothing about the README.Debian file. I
> suggest to add a section 6.8 (in the "Documentation" chapter) or something
> like that:
>
> 6.8 README.Debian
Something to this effect should de
On Friday 6 August 1999, at 22 h 21, the keyboard of Anthony Towns
wrote:
> I'd prefer to just say it should document these changes, rather than make
> it mandatory. :-/
I was thinking about the huge flame-war, both on debian-devel and on the News,
triggered by a paranoiac upstream maintainer
On Fri, Aug 06, 1999 at 11:59:38AM +0200, Stephane Bortzmeyer wrote:
> - the changes you made for the Debian package.
How does this relate to the second paragraph of section "6.5 Copyright
information"?
In addition, the copyright file must say where the upstream sources
(if any) were ob
Please, write shorter lines!
On Fri, Aug 06, 1999 at 02:40:06PM +0200, Stephane Bortzmeyer wrote:
> I don't think we should write the Policy by taking into account
> changes which will be integrated in the next twenty years.
Build-time dependencies can be implemented right now, as soon as we
agr
Stephane Bortzmeyer wrote:
> Your package may contain a /usr/share/doc/package/README.Debian
> file. It is mandatory to have one if you modified the source code of
> the upstream package.
Ah... I smell a Lintian check :-)
I second this proposal, by the way. It looks interesting.
> This file sho
On Fri, Aug 06, 1999 at 02:40:06PM +0200, Stephane Bortzmeyer wrote:
>>> - the rationale for choosing such or such options in the debian/rules when
>>> calling configure and/or make.
>> Why shouldn't this simply be in the debian/rules file where it's convenient,
> Hmmm, because debian/rules is rea
On Friday 6 August 1999, at 15 h 59, the keyboard of Antti-Juhani Kaijanaho
<[EMAIL PROTECTED]> wrote:
> How does this relate to the second paragraph of section "6.5 Copyright
> information"?
I've missed this line, sorry. Isn't it strange to have technical information
like this one in a "copyri
On Fri, Aug 06, 1999 at 02:30:51AM -0300, Nicolás Lichtmaier wrote:
> Why do you think that we couldn't make a decision now?
Because we haven't been able to do so in the last few weeks.
> And will those reasons go away in the future?
Perhaps. Perhaps not. But if it is indeed harmful for peopl
> "Stephane" == Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
Stephane> The current Policy manual says almost nothing about the
Stephane> README.Debian file. I suggest to add a section 6.8 (in
Stephane> the "Documentation" chapter) or something like that:
Stephane> 6.8 READM
On Fri, Aug 06, 1999 at 03:04:13PM +0200, Stephane Bortzmeyer wrote:
> I've missed this line, sorry. Isn't it strange to have technical information
> like this one in a "copyright" file?
Not at all. Changes made to a program are very much an issue of
copyright.
> Who will have the idea to read
On Friday 6 August 1999, at 23 h 2, the keyboard of Anthony Towns
wrote:
> Oh. I just didn't see any reason why a sysadmin would particularly care
> unless they were about to recompile it.
I agree with Richard Braakman: you have two sort of compile options. Those who
were necessary to build b
On Fri, Aug 06, 1999 at 03:24:26PM +0200, Stephane Bortzmeyer wrote:
> > Oh. I just didn't see any reason why a sysadmin would particularly care
> > unless they were about to recompile it.
> I agree with Richard Braakman: you have two sort of compile
> options. Those who were necessary to build bu
On 5 Aug 1999, Chris Waters wrote:
> Julian Gilbey <[EMAIL PROTECTED]> writes:
>
> > (I think the issue was with the /usr/doc->/usr/share/doc move, not
> > with FHS compliance.
>
> Yes, I'm trying to see the big picture, though. Why are we moving to
> /usr/share/doc? FHS. Well, then, what ab
On Fri, Aug 06, 1999 at 03:05:47AM -0300, Nicolás Lichtmaier wrote:
> > While everybody involved in this discussions sits and goes in circles, the
> > rest of the project is going to pass -policy by and just impliment policy
> > as it states in the policy manual and by the time the people who get t
Joey Hess wrote:
> Richard Braakman wrote:
> > Joey Hess wrote:
> >
> > > But when they do, they discover they can no longer read alien's man
> > > page, becuase their old man browser doesn't grok
> > > /usr/share/man. What to do?
> >
> > They can modify /etc/manpath.config to include /usr/share/
On 5 Aug 1999, Chris Waters wrote:
> Santiago Vila <[EMAIL PROTECTED]> writes:
>
> > I think there are several wrong assumptions here:
>
> Hmm, maybe so. Or at least arguable points. But these were all in
> the preamble, not in the proposal itself. The proposal was a pretty
> simple statement
Hi,
>>"Joseph" == Joseph Carter <[EMAIL PROTECTED]> writes:
>> 2) People used the `formal objection' mechanism to stop the answer just
>> because the didn't like. I don't think this was right. And the people who
>> did it are starting to realize that too.. =)
Joseph> too-many-chiefs syndrome,
Hi,
>>"Remco" == Remco Blaakmeer <[EMAIL PROTECTED]> writes:
Remco> The advantage of this proposal is that it buys time. Time to
Remco> come up with a really good transition scheme.
I am not sure that merely postponing the transition is likely
to enable us to come to a conesnsus on a `
Hi,
I have a couple of things to say about this proposal. I think
that we have a bad track record when it comes to merely deferring the
issue until a latter date (I point to the archive reorg issue, where
we were to have an unstable pool, a staging area, and a current
stable pool, whic
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I have a couple of things to say about this proposal. I think
> that we have a bad track record when it comes to merely deferring the
> issue until a latter date (I point to the archive reorg issue
Which is a political issue. We're bad at
Kai Henningsen wrote:
> [EMAIL PROTECTED] (Julian Gilbey) wrote on 18.07.99 in <[EMAIL PROTECTED]>:
>
> > Seconded.
>
> Seconded.
Note that there's a companion proposal to this, #40766. It currently has
only one second. Please look at it and consider seconding it.
--
see shy jo
Here's what's been happening on debian-policy this week.
Note: for details of the policy process, see
http://www.debian.org/~srivasta/policy/ch3.html. Also, this summary is
available on the web at http://kitenet.net/~joey/policy-weekly.html.
Accepted Amendments
Stephane Bortzmeyer wrote:
> The current Policy manual says almost nothing about the README.Debian file. I
> suggest to add a section 6.8 (in the "Documentation" chapter) or something
> like that:
>
> 6.8 README.Debian
>
> Your package may contain a /usr/share/doc/package/README.Debian file.
I
The discussion period for this amendment ended on Friday, the 6th of
August, 1999. However, we don't yet have a consensus. We do seem to be
on the right track, though, so I'd like us to grant the one-time one-week
extension to this discussion period. Thus the discussion should end on
Friday, the
36 matches
Mail list logo
