Craig Small wrote:
>
> On Wed, Apr 26, 2000 at 11:57:00AM +0200, Jens David wrote:
> > Of cause the new kernel needs new tools which will not work with
> > the old kernel. Thatīs why I released seperate distributions. I
> > orginally wanted to keep the new tools backward compatible. I modified
> > the autoconf scripts so that they tried to find out at compile time whether
> > they were being compiled for old or new AX.25 . I sent the patches to you,
> > but did not get any response. I concluded that there was no interest. Thus
> > I became quite sloppy about placing my #ifdefs during further changes.
> I don't recall an email, which address did you send it to?
I am pretty sure I sent it to <[EMAIL PROTECTED]>.
As I got no response I asked on the list if somebody had seen you recently.
No response.
> I do remember some discussion about non-backwards compatible API and how
> I and many others said it was a bad idea.
Joerg conviced me that keeping the old socket API for applications is
mandatory. However, I do not see why new user space setup utilities
need to work with (mostly) 3 years old kernel code? Do other tools such
as the hdparms etc. work with old kernel drivers? I honestly donīt know,
but I would not expect it to do so. The point why I am asking this is
because it bloats tool source and IMO makes it unmaintainable, thus again
causing potention error sources.
> OK, just so I know when to expect the torrent of emails saying their
> setup doesn't work are you telling me that a standard 2.2.14 kernel
> does not work with the plain vanilla ax25 tools or apps?
Remember we are talking about the future here, maybe one or 1.5 years.
> Checking at compile time for what sort of system you are running is just
> a totally bad idea. You do understand that the various distributions
> distribute binaries, ie they are compilied once?
Of cause, but as time comes I assume we will have re-merged the code.
> > I know that this will pose a lot of administrative problems. But I will
> > not accept any performance-compatibility tradeoffs here, except perhaps
> > the binary compatibility with the old socket interface.
> If I have read and understood things correctly, I don't think you
> realise what size of a disaster you are making for people, especially
> the distributions.
Not exactly, no. If you have a concrete idea which is better, then letīs
discuss it.
What I really do not understand is why for example listen is part of
ax25-apps while other low-level stuff is part of ax25-tools. Whereīs the
difference, why not one package for simplicity?
Why not call the resulting package "ax25-utils" again, any refs on the
original 2.1.43 (or whatever it was) stuff will surely be erased by then,
or at least nobody will have the bright idea to use 2.1.x-stuff with 2.5,
right? So this should be enough to distinguish both packages?
-- Jens
