sitting on my HD (on my Debian system) unless I'm actively using it
to advertize the Debian project. (To whom? Myself?)
Can we really call it the Debian logo if Debian developers (and maybe
even users) aren't allowed to use it?
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant
joost, he said I should go ahead
and bring it up on -policy, but asked that he be CC'd into the
discussions, since he's not subscribed to -policty. So, I'd like to
pass along his request now.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or
ckage can install menus items in any number of different menus. Look
> at bsdgames.
No problemo.
BTW, note that I cc'd joost on this. He asked to be cc'd into any
policy discussions about this topic. So, while it's probably a waste
of time, I'd like to request that everyone e
choose some packages from stable and some from unstable (and maybe
even some from experimental or whatever). Might be worth a wishlist
bug against apt, but it's not really a policy issue.
Followups should probably go to -devel or some other more appropriate
list. (-deity?)
--
Chris Waters
ent.
Argument for this amendment: it's more specific than JoeyH's, it
outlines *exactly* what to do, and is therefore more suitable for a
yeah-or-nay vote.
- --
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too l
ven if someone
decides to build a copy for themselves that uses true Motif.
The availability of *any* free option to make the software work makes
the software qualify for main. But if *all* the options involve the
use of non-free software, then it goes in contrib.
--
Chris Waters [EMAIL PR
Joey Hess <[EMAIL PROTECTED]> writes:
> Chris Waters wrote:
> > Therefore, this is a formal proposal to amend JoeyH's proposal as
> > follows: The existing menu heirarchy should be moved into policy
> By existing menu hierarchy, do you mean the one I put in my
>
ete objections or suggestions.
If there are any that we haven't already rejected for various reasons.
I think the menu system is too nice of a feature to leave hanging in
the wind the way it seems to be at the moment, so *any* movement on
this issue will be a good thing in my book.
--
Chris Wate
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Previously Chris Waters wrote:
> > Well, a) people don't pay attention to it, b) none of the discussions
> > about how and what to change have gotten anywhere, and c) based on the
> > evidence of b, there's
;s best to keep the heirarchy flexible and open
to future suggestions and requirements.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
f what you say is true (there's a free alpha-quality ICQ server
around), then ICQ clients can go in main under any circumstances.
Might even be nice to package up the server (at least for
projects/experimental).
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[
u policy and the menu heirarchy in general, over here
on -policy. I'm working on writing something up, and I'll be more
than happy to include this excellent suggestion in my proposal.
- --
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | a
equiring it in -dev packages.
But I'm open to debate.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
[EMAIL PROTECTED] (Marco d'Itri) writes:
> I'm opening a bug against the policy and I propose that those words in
> 2.1.3:
> "non-free", or "non-US"
> be replaced by the words:
> or "non-free"
Seconded (if there aren't already a
e it as policy. So, I'd like to have the proposal
vetted by someone who *is* a security expert before we act on it.
If there are no security issues (and I'm easy to persuade on this),
then I'll change my objection to a hearty endorsement. :-)
--
Chris Waters [EMAIL PROTECTED]
Joseph Carter <[EMAIL PROTECTED]> writes:
> > Bug:
> > Title: moving the menu hierarchy into debian policy
> > Posted: 01 May 1999
> > Proposer: Chris Waters
> > Seconders: Joey Hess, Karl M. Hegbloom
> > Status: stalled
> > Description:
> &g
o lock the screen
Save - screen savers
Root-window - things that fill the root window
WindowManagers - X window managers
Modules - window manager modules
XShells - xterm and its brethern
THREE: (cleanup) remove section 2.2 from
im must to move menu policy first, then worry about
> modifications, like those I have suggest above.
So is this a second? Would you rather wait till we clarify the
"Technical" section, and then second? Or no interest in seconding?
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Chris Waters <[EMAIL PROTECTED]> writes:
> Here is the authoritative list of Debian's menu structure.
Note to self -- detabify list next time, so it doesn't look so funky
when quoted. :-)
Joseph Carter <[EMAIL PROTECTED]> writes:
> On Fri, May 14, 1999 at 05:11:25PM -0700, Chris Waters wrote:
> > I'm working on a proposal to handle this in a similar fashion to the
> > virtual package list, i.e. as a separate list we can change when
> > sufficient ne
hing no other dist was going to) has been adressed.. Do
> we have a consensus now?
I posted an objection that I thought we should check with a security
expert to make sure there aren't any known security issues with this
idea. I don't know if that's been done, but the moment
Proposal has been seconded by Edward Betts <[EMAIL PROTECTED]> and
Joey Hess <[EMAIL PROTECTED]>.
taken into strong consideration. Obviously, the
maintainer gets the deciding vote, but it's good to stay on good terms
with upstream developers.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
if we can squeeze this in without disrupting the process, then I
will most definitely support this amendment or correction or whatever
it is. Maybe if we refer to this as a correction, rather than as an
amendment, we'll be able to slip it in under the same rules that will
(I hope) allow me to c
you mean!
If you mean (as I hope) that we should create standard categories for
use *within* the info and dhelp systems (and don't forget dwww),
that's not a bad idea, but it's unrelated to #37713. Come up with an
actual proposal, and if it's a good one, you'll have my s
I'm going to be away most of this weekend, till Tue, please don't let
the proposal die through indifference before I get back. :-)
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Joseph Carter <[EMAIL PROTECTED]> writes:
> I think we have one (consensus)
Oops, sorry for misinterpreting. Ok, I'll see about the next step
after the weekend is over.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | ab
shall hold in reserve in case this one proves
inadequate.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
f the pure-data packages to end up on CD three, but
won't be quite so arbitrary. But it's also a lot more work, and
involves possibly contentious value judgements, which is why I'm not
formally objecting to this proposal, just raising an issue for
discussion.
IOW, I'm not really
the upstream maintainer doesn't respond to his
email. :-)
Personally, I'd rather have the Upanishads in there if we're going to
have a "manual for living", but those could probably fill an entire CD
on their own.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegan
If you want the same effect, you can simply have EDITOR point to a
script which tests whether X is running or not, and calls an
appropriate editor, depending.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to f
traditional behavior of mailx, elm, rn,
trn, etc., rather than forcing these well-known programs to be
modified in ways that may disconcert people.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
h
to leave a wishlist item around so I can
think about it, but that doesn't necessarily mean I want to see
something implemented exactly as described in the report.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long t
g *some* support for bzip,
esp., when the upstream is available bzipped. That would make sense.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
be changed by the packager, but if possible it should be converted
> to maximum compression.
Whoah, you're saying that we can't convert zip archives (which may
contain EAs/resource forks) to tarballs? I think we're going to have
trouble with that one.
--
Chris Waters
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On 11 Jun 1999, Chris Waters wrote:
> > Whoah, you're saying that we can't convert zip archives (which may
> > contain EAs/resource forks) to tarballs? I think we're going to have
> > trouble with tha
Joseph Carter <[EMAIL PROTECTED]> writes:
> > But zip is non-free -- you're opening a major can of worms here!
> miniunz.
Cool! Learn something new everyday. :-)
cheers
not part of Debian, and probably never will be, have any
bearing on Debian policy?
OTOH, I oppose the proposal because I'd rather preserve traditional
*NIX behavior. I'd rather not have us have to make weird patches to
programs like mailx and rn that people (and programs) expect to have
work
ee --
in the package description.)
Back when non-us was all lumped together, this was a more contentious
issue; now that non-us is divided properly (about time imo!), it may
be time to reopen the issue, I'm not sure. I *am* sure that it would
make RMS happy if we finally got this resolved, but R
you not get a vote, but your input shall be ignored.
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
twice for no gain in
functionality.
Should I write up a proposal on this?
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
> Chris> Note that the common element of both proposals is that
> Chris> someone who has non-free packages in her package list will
> Chris&g
pstream promised one next release", or whatever seems appropriate.
Unlike undocumented(7), this could actually be somewhat useful, as it
would let the users know exactly what the situation is.
This is even something that lintian could check for, after a fashion.
The only really tricky bit I see wit
/check-sendfile || /bin/true
> + test -f /usr/local/etc/profile && . /usr/local/etc/profile
An excellent idea, but I don't think it's a policy issue. I think you
should file a wishlist bug against bash (which provides /etc/profile).
--
Chris Waters [EMAIL PROTECTE
anywhere, and go directly to the
> item you want, once you know the menu hierarchy.
Now, that's not exactly true. The local sysadmin may well have put
overrides in /etc/menu. But I agree that it's something to consider,
as this probably greatly increases the chance that things will not
-BEGIN PGP SIGNED MESSAGE-
Yes, this seems like a reasonable and satisfactory proposal, I will second.
-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface
iQCVAwUBN22HMzZs0/7rwRsBAQFdwgQAkBrgDrQADdPjLKEMBq/U28ejCwMVD
documented(7) will no longer
have the dubious blessing of being mentioned in policy.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
from the menu package itself (for developers
that want menu installed, and to prevent re-releasing menu just to
affect changes in policy).
We may even want to create policy for these hints, so that we don't
have hundreds of random, incompatible hints provided by different
packages.
--
Ch
any positive arguments in *favor* of undocumented(7)?
We've been unable to find anyone who can justify it or explain why it
was adopted as policy in the first place. But, of course, it *was*
adopted as policy at some point, so surely someone must have had a
reason, and many of us, includin
rmation. Which I do not have at this point.
~ $ ls -lR /usr/man | grep undocumented | wc -l
241
And that's without even looking in /usr/X11R6/man.
The rampant and widespread use of undocumented(7) is, IMO, starting to
create a disincentive for users to even bother with man at all! I
hope t
Mark Brown <[EMAIL PROTECTED]> writes:
> On Tue, Jun 22, 1999 at 03:32:35PM -0700, Chris Waters wrote:
> > Can you provide any positive arguments in *favor* of undocumented(7)?
> One thing undocumented(7) does is suggest some other ways to find
> documentation.
So coul
purpose.
The cure seems to be worse than the original problem.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
like, "it's not hard to make a two line man
page that points to the actual documentation, so undocumented(7)
should only be used in cases of extreme duress." Or something like
that. :-)
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROT
if no better proposals come forth, and it becomes clear that
people *do* understand that this particular proposal *is* a
technically inferior one, but the general consensus is that the
aesthetics are more important, then I'll probably be willing to
withdraw my objection. But not until then.
chee
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
> Chris> Which leaves the "user is used to '/usr/doc'" objection, which is a
> Chris> *purely* aesthetic objection, not a tec
an stand out is that we *do* try
to take the time to do things right. And that's why I'm dubious about
a stop-gap. I'm also concerned that we may be stuck with these
symlinks for much longer than we'd expected if we do use them. The
whole idea of a proposal that proposes a f
extra panic and mayhem. But that's a
whole 'nuther topic that deserves its own lengthy discussion.
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
ssary. Just let me know how. (Should I talk
to an SGI officer?)
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
> Chris> It may be too late. We *NEED* consensus on this sort of thing:
> No, we do not need a consensus. The DPL can still mandate a
>
ending) proposal as well as for yours. I'm
trying to be realistic here.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
n
Woody (I think we can do it), or b) go with the symlink proposal (and
mere FHS-compatibility) *at that time*.
OTOH, I don't think the multiple locations proposal is without merit
either, and I wouldn't mind seeing some discussion of that.
In point of fact, I don't think the symlink p
my position more clear.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
y not want to move back.
+ may not need crufty symlinks.
+ gives us a little more time to decide if we want crufty
symlinks, and if so, what's the best way to handle it.
+ no surprises to the user.
+ no changes to most packages till after potato's release.
--
Chris Wate
Anthony Towns writes:
> [1 ]
> On Sat, Jul 31, 1999 at 12:40:39AM -0700, Chris Waters wrote:
> > * Stick with /usr/doc until potato is released, then begin a massive
> > migration, which may or may not involve symlinks.
> > - we can't pretend FHS compl
we *should* have some sort of link between policy
and our actual release cycle, but we don't yet, and I want to make
sure that no one will object to my proposal on *that* ground.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above,
of last-minute details.
Expect such a proposal *very* soon if no one objects.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
ittle more firm (there was
only one formal objection, but a *number* of negative comments on file
when I posted my objection).
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
force
measures *somehow*. Let's make sure we have the more subtle,
inobvious, and tricky bits under control before worrying about it.
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
games are 755 `root.root'."
New:
"The permissions on /var/games are 755 `root.root'. Games which
use the FSSTND /var/lib/games should be modified to use the FHS
/var/games instead."
I'm not sure if this needs seconds, since it's more of a correctio
ers, I used it. :-)
> Some of the formal wrangling seems to be getting in the way of
> finding and discussing an acceptable solution however.
I think it's just a complex issue. Those do occur once in a while. :-)
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a trul
maneuver. I'd hate to see us set any unfortunate precedents here (as
very nearly seems to be happening, with people inventing the "five
formal objections" rule). I'd like to keep the proposal policy
reasonably *in*formal.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elega
of order, we're
just going to make matters worse, IMO.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hi,
> >>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
> Chris> There is more involved with FHS than I think many people
> Chris> realize. We have a fair amount of work to do just with
y Standard
(FHS). The latest version of this document can be found
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
-BEGIN PGP SIGNED MESSAGE-
Steve Greenland <[EMAIL PROTECTED]> writes, in Bug#41121:
> Add the following section 5.4 as the next to last paragraph (i.e. before
> the one beginning "Since the Debian base system...").
> A program may also use the VISUAL environment variable [...]
I se
the FHS. (No patching of binaries required.)
So, *why* are we in such a *panic* about /usr/share/doc now? (This is
a rhetorical question, in case it's not obvious.) :-)
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is
mittee something else to
consider if Manoj *does* send his proposal to them! :-)
I think that with the number of seconds I've recieved (thanks guys!),
this proposal is now too strong to ignore, even if it doesn't make it
through the debates here. Which is really what I wanted. Formally
o
Joseph Carter <[EMAIL PROTECTED]> writes:
> On Wed, Aug 04, 1999 at 04:02:14PM -0700, Chris Waters wrote:
> > PROPOSAL (0.9): delay the /usr/share/doc transition
> The problem with this is that there are more than 100 packages using
> /usr/share/doc already, and there likel
well
thought out. Now all we need is a *workable* proposal or six. :-)
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
that's just a backup plan.
A worst-case scenario. And the rest of your logic falls apart, since
it hinges on the ridiculous theory that I didn't make this proposal
because it was the solution I wanted to see implemented.
So, do you actually have any comments about the PROPOSAL?
cheers
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
like the requirement to add postinsts to all the packages
that currently lack them, possibly for eternity, certainly till at
least Woody+2 or +3 (which I wasn't aware of until *after* the
proposal was already mooted).
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
x27;s only so much that
can be done today. Either we institute temporary policy with *no*
markings and *assume*[1] that we'll fix it later, or we clearly mark
it as temporary policy when we all know that it is temporary policy.
I think the latter is *far* preferable.
[1] and you know what &qu
nent policy somehow.
p.s. I find it much easier to debate these issues when you're
remaining calm and rational instead of hurling four-letter invective
around the place, which sometimes causes me to lose my own cool.
Let's see if we can keep this up. :-)
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
t we have to deal with very often. :-)
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hi,
> >>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
> Chris> Sorry, I'm not saying the latter is an inherently bad thing to
> Chris> do, I'm saying that if that's our *only* opt
posal, you said explicitly that you would support such a proposal.
You are one of the people I had on my list of obvious seconds. And
yet, when I actually made the formal proposal, you suddenly decide
that it's evil and horrid. And pose some very strange, and, frankly,
obscure objections. Forgi
en* start the seconding process! :-)
(Consider this an intent to second, contingent on fixing this rather
obvious problem.)
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
-BEGIN PGP SIGNED MESSAGE-
Joey Hess <[EMAIL PROTECTED]> writes:
> + only. Architecture-specific example files should be installed in a directory
> + /usr/lib//examples, and files in
> + /usr/share/doc//examples symlink to files in it. Or the latter
> directory may be a symlink to the f
obably increases the chance that the statically linked binaries will
survive a hostile break-in.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
-BEGIN PGP SIGNED MESSAGE-
Joey Hess <[EMAIL PROTECTED]> writes:
> + only. Architecture-specific example files should be installed in a directory
> + /usr/lib//examples, and files in
> + /usr/share/doc//examples symlink to files in it. Or the latter
> directory may be a symlink to the f
ut I think *most* people expect, prefer, and
just plain *want* bash to be /bin/sh. I very much feel that we should
keep bash as the *default*, but we should definitely make it easier
for people who want to use something else as /bin/sh.
--
Chris Waters [EMAIL PROTECTED] | I have a truly eleg
.
Like I say, if you want to make *optional* packages for the paranoid,
then I have no objections. If you want to make this standard, then I
strongly object.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
ost things.) But I object to making a bunch of
statically linked binaries standard!
Is that so hard to understand? This is NOT SOMETHING EVERYONE NEEDS!
So it should be OPTIONAL! Am I speaking in words of sufficiently few
syllables yet?
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a tru
't have them crammed down
their throats.
First, though, you might want to investigate sash.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Michael Stone <[EMAIL PROTECTED]> writes:
> On Tue, Aug 17, 1999 at 01:44:00PM -0700, Chris Waters wrote:
> > *compliance* is a big issue to me, but I'd be open to allowing the use
> > of ash as /bin/sh *as an option*. Oh wait, it already is! :-)
> No it's not
policy isn't changed.
So, there's really four proposals, not two.
Oh, and I did point out a couple of very minor, but still ACTUALLY
TECHNICAL objections to Manoj's proposal. Executive summary: symlinks
have limitations, and if we add an extra layer of symlinks, we
increase the (
Anthony Towns writes:
> [1 ]
> On Wed, Aug 18, 1999 at 04:25:48PM -0700, Chris Waters wrote:
> > First of all, I'm still not convinced that this is a technical issue,
> > as I mentioned in my objection to Manoj's proposal.
> "How do we keep all the document
nd.
> "Hmmm. Changing all packages is going to a fair bit of time -- it has in
> the past, for libc6 and stuff.
Yes, that's why I suggest that we wait till after Potato, and start
the changeover at the *beginning* of a release cycle. That way we
have as much time as possible.
c
of us think that we're *too* focused on releases, and
some of us (like me) think that we're not focused *enough* on
releases, then maybe we're actually striking exactly the right
balance. I dunno. :-)
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
1 - 100 of 397 matches
Mail list logo
