ave to, or b)
as a proxy for upstream? I tend to lean towards the former position;
it sounds like you lean towards the latter.
Bottom line: it sounds like you think the java example is
fundamentally wrong; I merely see it as flawed, awkward and hard to
maintain: a bad idea in general, but n
ourse,
sometimes you don't want to remove it. In that case, try this:
if [ "$(echo * .*)" = "* . .." ] ; then echo empty dir; fi
No overhead for calling external programs, except echo which is a shell
builtin. No calls to ls, wc, or grep. Simple and fast, if a little b
Cylord wrote:
> On Tue, Nov 17, 1998 at 03:05:08PM +0100, Richard Braakman wrote:
> > Chris Waters wrote:
> > > if [ "$(echo * .*)" = "* . .." ] ; then echo empty dir; fi
[but]
> > touch *
[fixed by]
> if [ "$(echo * ? .*)" = "* ? . .
pload to
frozen. The end result of all of this is that I'm very confused. :-)
--
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.
Stephen J. Carpenter wrote:
> On Fri, Dec 04, 1998 at 01:04:26AM -0800, Chris Waters wrote:
> > I've taken over maintaining an already packaged program. Should I
> > upload to frozen so that I'll be the maintainer-of-record when it
> > becomes stable? Does the f
help
today. Does anyone have any suggestions, or better yet, examples of
other packages that have had this problem, and how it was solved?
--
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
he program should
> detect when a config file is an old version, and offer to delete it.
Hmm, ok, I already said I thought this was the best long-term solution.
But it doesn't answer the question: what do I do now? Not upload the
package until this gets resolved upstream? Could be quite a w
s if you're really curious.
--
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't actually conflict with anything, and
changing the name of the binary may break things if anyone is using
existing versions of my xproc. Or should I use some other name for my
xproc package? That would avoid conflicts and breakage, but would
surely be confusing.
Suggestions?
--
Chris Waters
ch that means "test build, not a
releasable product." But aside from that very minor quirk,
cvs-buildpackage is an excellent product, and I highly recommend it.
Very easy to use, and very useful.
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
n't work for you, and to be quite frank, you've
made me a little nervous now. After the success of my first attempt, I
was planning to relax and enjoy using cvs-inject, but now I guess I'll
have to keep checking this sort of thing very carefully.
--
Chris Waters [EMAIL PROTECTED] |
11 matches
Mail list logo
