On Nov 10, 2005, at 7:13 AM, G.W. Haywood wrote:
No one will force you to upgrade and the source is always there if
you need a 3.5 version.
Ah, it must be wonderful to have such a rosy view of the world. :)
Ah, it must be nice to feel to smugly superior with your
understanding of how things ought to be :)
That's not exactly true, is it? The distro maintainers will be
forced to use the latest versions in their offerings.
Distro maintainers might actually want to consider, I don't know,
maybe offering whatever they feel their users want.
As a FreeBSD user, I've installed ncftp2 and ncftp3, although neither
was installed by default. I chose which one I wanted to install.
Same with perl.
Occasional discoveries of exploits and vulnerabilities and the
resulting security fixes mean that it's not feasible to use an
older distro.
At which point the 3.x branch could be updated. You'll see I
previously suggested a "3.5 version". Since the current version is
3.22 I thought that was clear that 3.5 would be a later version which
fixed problems in the 3.x tree
If the much-feared GFC phenomenon takes hold, it will mean that
whenever one installs a new Linux system he'll be landed with a
terrible dilemma: either to use the latest (untried, flaky, bug-
ridden) versions and possibly to have to make major and time-
consuming modifications to a lot of very personal configurations
(which he may have worked on for many years); or to downgrade a
bunch of packages - which, as it's for every new blessed
installation, ultimately will take even longer. This is not
theoretical. This happens, and it costs a lot of time. Have you
ever had a script broken by an upgrade to the latest version of Perl?
Nope, never.
Of course I have, but if you read the suggestions others had made,
the features which were suggested would require someone explicitly
requesting that a recipe/RC file be parsed differently.
So tell me how this would cause problems?
Next you'll want to improve the shell. Please, leave them alone!
Yeah, like those bastards who gave us bash as a default instead of
sh. Damn them. And people who want a static version of something
like 'pico' to be installed by default in addition to just 'vi' who
get shouted at because of all the ancient Un*x jags who think it's a
noble rite of passage to have to learn that arcane stupidity rather
than using something clear.
Of course there will be a few bugfixes now and then, and
occasionally this will break a script or two which arguably were
themselves broken, but major new developments need to be 'opt-in'
not 'find-a-way-out'. I have absolutely no objection to anyone
having some more features if they want them, I just don't want
development to screw things up for everyone else in the process.
Or as Bert Lance so eloquently put it:
If it ain't broke, don't fix it.
But what you, and others, are refusing to see is that it IS broken
for many of us. Because it isn't broken for you, you want to freeze
it in time, except for eternal security/bug fixes (as long as "bug"
doesn't include "the need to make repeated calls to external programs
for things which could appropriately be handled within procmail")
Is there anything unacceptable about branching a new utility called
'procmail2' or something like that? It seems to me this could
offer something from both worlds, if not necessarily the best of
them. If it turned out that it was overwhelmingly more effective
than the old version people would migrate to it, and eventually the
older utility would die a natural death. Nobody would be seriously
inconvenienced in the process. The distro maintainers could
package both, something as small as procmail wouldn't make much
difference to a 650MByte ISO if there were two alternatives - after
all have at least six window managers kicking around on this
Slackware box.
I have a recollection of suggesting that very thing myself earlier in
the thread, even having referenced the fact that people have perl4
and perl5 installed and suggested 'procmail3' and 'procmail4'.
Perhaps that reply went to a poster rather than to the list.
I think the likelihood of a serious flaw being found in procmail is
low, and if it was, I suspect it would be patched within a day of the
report. (I also think the chances of a flaw being discovered by
someone who isn't malicious would increase if we had some renewed
development going on and people were actually examining the source
code again.)
TjL
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail