This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

AW: SETUP WIZARD FOR CYGWIN?XFREE


Ralf Habacker wrote:

> in some points I agree with you, I have added some necessary libs like
> png,tiff,gif,zlib from a current cygwin distribution because for preventing
> of version conflicts.


Ralf, why did you do this?  We've already gone over this -- and, given 
the deference I have given the xfree team w.r.t. defending Suhaib's 
position on libfreetype, changing my xpm package which predated the 
xfree version, etc, I expect reciprocal respect from you guys.

Why are you forking my cygwin packages?

If you are worried about version conflicts, there is no need.  Now that 
the early growing pains with dlls (the infamous dll-naming thread on 
cygwin-apps, the libfoo.dll to cygfoo.dll transition, the .dll.a 
convention) are behind us, the only time dll names in the main 
distribution will change is when the ABI/API changes -- which would 
require relink/recompile anyway.

AND in those cases, the old DLLs will continue to be supplied -- take a 
look inside the current readline-4.2 binary tarball.  You'll see 
/usr/bin/cygreadline4.dll (from the 4.1 dist) AND 
/usr/bin/cygreadline5.dll (from the 4.2 dist).  You'll see 
/usr/lib/libreadline.dll.a which is the import lib for cygreadline5, so 
that all new progs will use the new dll.  BUT, older progs will continue 
to work because the old dll is THERE.

There is no need to distribute copies yourself -- and in fact, that is 
harmful.  Please don't do it.  Did you even read this message?

----------------------
Re: AW: ask for delivering cygwin 1.1.8 with kde 1.1.2

http://www.cygwin.com/ml/cygwin-apps/2001-06/msg00057.html


I think we're slowly converging on a system in which:
   when a library is updated so that the new dll is not backwards
compatible (that is, the DLL name changes to represent an ABI/API
incompatibility), then we try to insure continued operation for a
reasonable time.  "reasonable" is open to interpretation.

There are two ways to do this:

1) the new package contains the headers, import libs, DLL's and static
libs for the NEW library, AND contains the old DLL's.  This is what we
chose to do with readline.

2) or the incompatible library is released with a different package
name.  However, since in all likelihood, the new package will contain
files that conflict with the old package, the old package should be
simultaneously updated to a new *version*, that contains only the DLL's
-- since the names are different, those won't conflict with the DLL's in
the new package.

In effect, both options are the same.  1) is simpler, and easier for us
volunteer maintainers.  2) makes it optional whether the use wants to
download a bunch of (useless?) old dll's, and is more in line with the
way most linux distributions handle it.
----------------------

Now, I realize there are reasons for the cygwin1.dll-1.1.8 thing and the 
cygwin1.dll-post-1.3.2-snapshot thing.  That's different.  I'm 
complaining about the duplicate distribution of stable dll's.  Just as 
Suhaib was justified in complaining about Xpm.dll, I feel justified in 
this.

Of course, it's all GPL -- I can't stop you.  But I really believe that 
duplicate distribution will only cause trouble down the road.

Unless, of course, you want to volunteer to take over maintainership of 
those packages (zlib, libpng, libtiff, libjpeg, libjbig).  That too is a 
possibility -- I am looking for somebody to take over...

--Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]