[Pan-users] Re: Anyone get pan compiling with gcc 4.3 yet?

[Duncan]

Daniel Rahn <address@hidden> posted
address@hidden, excerpted below, on  Sat, 05
Apr 2008 10:20:51 +0200:

> Not everybody recompiles half of the distribution day after day.

What, not everyone wants to run Gentoo as I do?  Why, I'd have never 
guessed! =8^)

(OT but... OTOH, after my recent upgrade to dual-core Opteron 290s on my 
dual Opteron box, so quad-core, I realized that for most stuff, compile 
time is now almost trivial, compared to the other stuff, figuring out 
what's new, config, etc, that comes along with installs/upgrades and that 
people have to do regardless of whether they use a binary or source based 
distribution.  As a result of this personal experience, I'm now convinced 
that in a few years, a couple Moore's law upgrade cycles, when this sort 
of machine is no longer a monster but in fact rather normal, some source 
based distribution, probably /not/ Gentoo as it's too power-user 
oriented, but someone, could easily break into the top three distribution 
list.  Imagine if you will, with compile time no longer a major factor, 
people will choose their distribution based on the usual things they 
choose it now on, packages available, support, ease of use in general, 
quality and ease of use of automated config tools, etc.  Source based 
does have a few advantages as does binary, but for most today the compile 
time factor vastly outweighs any other consideration.  When that's no 
longer the case other factors will be a greater influence, and while 
source based will be stronger in some areas and weaker in others, it'll 
be those factors influencing the decision, not source vs binary or 
associated compile-time worries directly.  What a difference that could 
make!)

> There are people that just _use_ the machine and require a bugfix once
> in a while. So if the distribution is still maintained, I don't see why
> a bugfix in svn should break compatibility.

Agreed.

> And after all, glib changed the API, not PAN. One project ignoring
> unwritten rules (never change the API without changing the major
> release) should not make other projects follow the same path.

Absolutely right!  There are times an API change is useful or necessary, 
but other things depend on them (sort of the definition of API, right?) 
so it shouldn't be willy-nilly, and when they occur, a clear break, 
traditionally indicated by a major version increment, should be part of 
the process.  All this trouble with glib for a minor version increment... 
Why?  Just... why?  What else is there to say?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman