Re: too much for an NMU?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> I think I understand the argument, but I also think I disagree. I
> think it's a Bad Thing to make this work differently from the upstream
> version, whatever we do. Front-ends (e.g. pilot-manager, maybe
> others) may look for the output on a particular stream and be
> surprised (and fail to work) when it doesn't appear where they expect.
True. Breaking from upstream would cause that kind of problem.
> I've been thinking of hacking up an Emacs interface to pilot-link, and
> I want to make something anyone can use, not something Debian-specific.
Mmmmm. Sounds crunchy.
> In response to the original report (which I have onscreen now), the
> output *can* be filtered now, it just requires more intelligent
> filters. :-)
I read that as: Time coding a rather complicated workaround code. Whilst
I enjoy very clever code as much as the next guy, a simple fix at pilot
link would help this immensely. I'm sure I don't need to mention the cost
maintaining the code (something else to break or be migrated) or how
easily fixes-for-other-people's-bugs become obsoleted and have to be
removed later (read "when they're more entrenched"). Oops, I just did.
Oh well. We need to try to nip this in the bud.
> If we can persuade upstream to make the change, then ok, otherwise, I
> *strongly* vote no. The report should either be forwarded or closed,
> probably the former. In NO WAY should it be "fixed" by us! Debian
> does not exist in a vaccuum.
True, but we also don't maintain compatability to upstream buffer-overruns
in sendmail or, more relevantly, programs that don't conform to the FS
policy. What we have here is a program that doesn't operate the "right
way" and makes it more difficult on developers and users. Look at the
addition of the I option to the Debian tar, bz2 support was easily (and
simply I might add) to give Debian users the functionality that they
desired. Not that I disagree with your suggestion. I believe this need
be corrected upstream as well. I propose a fairly simple (read: easy to
code/nonintrusive) interim solution. Add either an environmental variable
(like PILOTRATE) that specifies the stream go to stderr (or perhaps a file
or file descriptors--but that would be not very portable :( ) or a new
commandline option (communicate with upstream to find out which one we can
use safely) which will do the redirection.
Actually, why not do both? Add an option to put the status messages to
stderr and an environmental variable to specify default options. Together
those changes wouldn't take 20 minutes (i.e. roughly 2 hours)--and they'd
be worth the trouble to all of the people who could use the stderr option
to remove an unnecessary special case from their code.)
- --the overly serious should stop reading here and skip to the end--
The reason I run Linux instead of Windows is because I shouldn't have to
jump through the flaming hoops that I used to jump through--just make my
computer do the "right thing". I run Debian instead of RedHat because I
want to be able to fine tune my system in ways that RedHat cannot.
Similarly I do so because I also enjoy the consistency that Debian often
provides (read: FS policy, PERL policy, policies YEAH!). I shouldn't have
to code around something that should not be there. RMS didn't start
writing GCC or EMACS because he wanted to waste time. He did it because
he wanted to do the "right thing". He wanted to give the world a free
choice. An option. Well, pilot-link deserves the option as well. An
option to have the program function the way it should!
I believe that the addition of this option (and a way to make it
default/specify options in an environmental variable) will contribute
positively to the Debian project. Do this not for yourself. Do this not
for your code. Do this not for your country. Do it for the children--so
that they may have the option to use stderr.
Today it's pilot-link, but this problem is indicative of a greater evil.
Someday, even errors may not be allowed on stderr! It's a slippery slope
and it's up to US to keep from sliding down into the morass of inefficient
code with mixed status and output streams. Help me stop it before it's
TOO LATE!!!
- --end of pro-stderr FUD campaign--
> Cc'd to the bug report because I think this is a *very* important
> point. I've set reply-to back to the list, please adjust if really
> necessary.
This is an important point. I think that the above solution would be a
very good one--it's non-intrusive, upwardly compatible, and defaultable
(Pilots exist because they're convenient, their tools should be so too).
At the risk of sounding like Microsoft, I believe that Debian extensions
should be enacted to enhance the operation of apps--but also to keep them
compatible and open (just like the tar enhancement, for instance).
- --
Jayson "Raving Lunatic" Vantuyl
P.S. It's a full moon in Missouri. That's why I did it.
Disclaimer: FUD is a registered TradeTactic of the Microsoft Corporation.
Everything in this document that is owned by someone other than Jayson
Vantuyl, belongs to the respective owners. Everything else is donated to
the public domain so they have to deal with it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: Made with PGP4Pine
iD8DBQE3noY8lBv9MedxyboRAg72AJ4uRZYRUTMHpT/ZOo8dxWz7B9gn3ACgokvx
KiJSv5lPOKd864pj+Jt7/Fc=
=It+J
-----END PGP SIGNATURE-----
Reply to: