Manoj Srivastava wrote:
Hi,
Mike == Mike Goldman [EMAIL PROTECTED] writes:
Mike Given then a choice between automatically moving all docs back
Mike to /usr/doc or moving all legacy packages to /usr/share/doc, I
Mike would choose the latter, since this is compliant with FHS which
Mike
Chris Waters wrote:
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
This proposal defers nothing. It merely mandates a *delay* for the
transition. Granted, it does
[not cc'ed to the bug report]
On Sun, Aug 08, 1999 at 05:04:01PM -0400, Mike Goldman wrote:
Richard Braakman wrote:
Mike Goldman wrote:
Therefore, I formally object to this proposal.
You have given reasons for not liking the proposal, but no reasons for
it being unviable. I think a
From: Stefan Gybas [EMAIL PROTECTED]
Yes, as Roman pointed out: lprng provides lpr but some package (I
don't remember which one it was) needs the real lpr to build, so you
can't just say Build-Depends: lpr.
Does it run with lprng but only build with the real lpr? If so, its a
bug, that it
Does it run with lprng but only build with the real lpr? If so, its
a bug, that it doesn't compile and should be fixed. If it doesn't
run or compile with lprng, it should depend on the real lpr.
I don't know if it runs with lprng But in any way, it can't depend
only on the real lpr, as
From: Roman Hodek [EMAIL PROTECTED]
Does it run with lprng but only build with the real lpr? If so, its
a bug, that it doesn't compile and should be fixed. If it doesn't
run or compile with lprng, it should depend on the real lpr.
I don't know if it runs with lprng But in any way, it
Hi,
Joey == Joey Hess [EMAIL PROTECTED] writes:
Joey I just realized something. With all this furur over /usr/share/doc,
Joey we seem to have skipped right over the question of where do
arch-dependant
Joey example files go. Where?
Since they are jsut examples, I think they can be
Hi,
Chris == Chris Waters [EMAIL PROTECTED] writes:
Secondly, I think that the policy should not hard code release
names
Chris I would call this a serious flaw in policy then.
My opinion is a flaw in policy? ;-)
Chris I think we NEED a way to say, these are the rules for release
Manoj Srivastava wrote:
Since they are jsut examples, I think they can be classified
as akin to documentation, and still go in the usual place, namely,
/usr/share/doc/package/*. There is no harm done, and no loss of
functionality.
Well there's a small loss, should someone actually
This message is being sent primarily to the debian-policy mailing
list, with a carbon-copy to another low-traffic list; I've set a
reply-to to the policy list and myself, but don't know if it will
stick.
I write to you as someone who wants to tell you what I wish to see in
a Debian distribution
Manoj Srivastava [EMAIL PROTECTED] writes:
Chris I think we NEED a way to say, these are the rules for release
Chris X, these are the rules to follow subsequently. Ideally, I
Chris think we'd have a strategy document that takes precedence over
Chris policy, but that's a fairly major
Joey Hess [EMAIL PROTECTED] writes:
I'd rather have /usr/lib/package/exmaples, with
/usr/share/doc/package/examples linking to it.
Yes, that seems like the most appropriate way to deal with example
binaries. Lets hope, though, that example binaries is not something
that we have to deal with
On Mon, 9 Aug 1999, Brad Allen wrote:
this package have been upgraded from FSSTND 1.2 (or whatever it
was) to FHS 2.0; please see FHS 2.0 at http://www.pathname.com/fhs/
for details on FHS'', in case some other package developer or
maintainer is still running a FSSTND system
13 matches
Mail list logo
