Re: cdrtools-2.01a22 ready
> >> Cdda2wav (By Heiko Eißfeldt heiko@hexco.de):
> >>
> >> - Now using the major() macro for some Linux duties.
> >>
> >> WARNING to creators of Linux distributions:
>
> >As such wording sounds very much as "political statement," I feel
> >necessity to comment on following.
>
> It is definitely not politocal but it tries to be so simple that even
> the morons you typically meet on the LKML will understand it :-(
^^^ Speak for yourself, please!
All right! Then you should have written "WARNING to those [morons(*) I,
J. Schilling, typically meet] on LKML" and not something as politically
loaded as "creators of Linux distributions," which basically refers to
e.g. Suse, Mandrake, Redhat, etc.
(*) As mentioned earlier I personally can't find such expressions
acceptable on public lists. This is exactly kind of wording which breaks
the trust and tears the community apart.
> >> It has _always_ been wrong to compile software only once for different
> >> kernel versions (e.g. for compile Linux-2.4 and later install a
> >> 2.2 kernel on the so created system).
>
> >I can't find the above statement to hold universally true. I would
> >accept "it has always beed wrong to compile *cdrtools* only once for
> >different kernel versions," but I refuse to accept formulation as broad
> >as above. There is possibility that author's intention *was* to make
> >statement about cdrtools in particular, in which case a clarification
>
> Sorry, Linux-2.6 _did_ definitely change interfaces in an incomptible way.
*All* [kernel] interfaces? Once again! I can't find the statement in its
original wording, i.e. as "it has *always* been wrong to compile
*software* ..." to hold *universally* true. I can accept "it's wrong to
compile *certain* software," preferably accompanied by solid explanation
*why* it's wrong. *If* your statement [in its original wording] was
actually true, then noone would ever be able to dual-boot same
root-partition on 2.4 and 2.[56].
> >note would be appropriate. Meanwhile I can say that I disagree with the
> >above statement in its current wording, because it's perfectly possible
> >to design software for backward binary compatility and even for two-way
> >compatibility. Moreover! Creators of Linux distributions *should*
> >actually strive for at least backward compatibility in maximum possible
> >extent, i.e. programs compiled under elder distribution should work and
> >even be supported under newer release, unless there is stronger reason
> >not to. I mean "it works in latest distribution if recompiled" per se
>
> And this is definitely wrong!
What is definitely wrong? Is it definitely wrong to *expect* developers
to *strive* for binary compatibility between kernel [or even
distribution] releases? That's what it says above! Do you disagree with
assessment that Linux would provide better foundation if binary
compatibility would be #1 design goal? You can't possibly disagree, as
this is exactly what you're complaining about, aren't you?
> Unfortunately, Linux-2.6 did change iterfaces in a way so it is impossible
> to run all applications compiled under earlier releases.
>
> This may be proved by looking at star: As the major()/minor() macro did
> change in an incompatible way, star just _cannot_ work correctly if you
> mix versions. Star compiled for pre-2.6 does not handle device nodes
> correctly on 2.6 and this is _not_ caused by a bug in star.
>
> As it has been prooven,
OK, I've just compiled second star binary. I mean I've had one compiled
under 2.4 (left from Dec 2002, when you posted request for help with
mkisofs -dvd-video:-), so I've compiled one under 2.6 too... Well, I
can't confirm your experience, as archive files produced by both
binaries are identical and they both cross-extract correctly. I
therefore have no other choice, but to challenge your proof:-) But see
even below!!!
> that there are problems with at least one program,
> what is wrong when I warn people that there might problems with other
> programs also?
As already mentioned, wording is wrong. As already implied, "It has
always been wrong to compile at least software written/maintained by me,
J. Schilling, ..." would be *perfectly* appropriate. You can strenthen
it by saying "I, J. Schilling, concluded that it has always been wrong
to compile every piece of software I have examined ...," but you can't
possibly mean as broad as "It has always been wrong to compile
software..."
> I am just warning people that unless they did 100% prove that every single
> aspect of a program will work correctly, if you run it on 2.6 vs. non 2.6
> systems, it is more safe to assume that there is no binary compatibility.
Well, are you positive that this is actually a kernel incompatibility
issue and not glibc? I bet you are not, as that's what it has to be,
binary incompatibility at glibc level! Meaning that you can fall victim
to this problem even under 2.4! Formally speaking if binary
compatibility can't be provided at run-time, then application should not
start at all (e.g. complaining about unresolved symbol or someting) or
glibc should modify its behaviour appropriately. Yes, major() is a
"jaw-breaking" case as it's compile-time macro, yet, the issue *can* be
addressed at run-time and it's no excuse for breaking binary
compatibility without at least run-time warning. This is exactly what I
mean by "Creators of Linux distributions *should* actually strive for at
least backward compatibility in maximum possible extent, ..." But one
way or another, I can't agree that referred case has something [if
anything] to do with Linux 2.4 vs. 2.6 kernel issues per se as
originally stated. Cheers. A.
Reply to: