Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3B1AA444.BA3AA2FE@ece.gatech.edu> Date: Sun, 03 Jun 2001 16:55:32 -0400 From: "Charles S. Wilson" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Karl M CC: robert DOT collins AT itdomain DOT com DOT au, cygwin AT sources DOT redhat DOT com Subject: Re: [avail for test] readline-4.2-1 also xpm and xpm-nox References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Karl M wrote: > > Hi All... > > For now, could you just include the extra library in the new release? No. They come from different source code bases. Yes, technically the readline-4.1 source code is already on the cygwin mirrors -- but if you install cygwin's readline-4.2 package (which, under your plan contains the 4.1 DLL's) and you click 'install source' -- then you should get BOTH sets of source code, not just the 4.2 code. However, I don't want to comingle the source code; I believe that's a bad idea and sets a bad precedent. Therefore, if the 4.1 and 4.2 source packages are to remain separate, then the 4.1 and 4.2 binary dists must remain separate. Anyway, I've already promised not to upgrade 4.2 from its current 'test' status until the only official external dependent (postgres) is ready...so what's the problem? > To > give time for the change over? Wouldn't that let setup-2.57 still do its > thing correctly for almost everyone? Yes, it would allow setup-2.57 to "do the right thing" -- if by "do the right thing" you mean "encourage people to ignore the changes and provide no incentive for upgrading to the bugfix/better release". If you *WANT* to use the old DLL's -- you can. No problem. I just haven't made it brain-dead-easy to do so. The old dll's are right there on the web server (and probably they are right there on your current installation). I don't really WANT to make it easier for people to keep them -- because that means I must continue to support obsolete variants, and I'm not going to be around long enough to do that. I've made it *possible* for people to keep the old dlls. It's actually pretty easy to do so. It's just not automatic nor is it brain-dead-easy. Aside: Personally, I'm not all that happy about the external API changes in readline. I think the package version number should've been bumped more than a minor digit. Also, there were MASSIVE formatting changes (and 'const' qualifiers were added all over the place) so my old patch -- 200k of changes that were ignored by Chet -- had to be reapplied by hand over the last four weekends. And the response I get? More complaints. So typical of this list. > Does this approach also apply to xpm xpm-nox? Could the new release also > include the old library for a while? No. The whole *POINT* of the xpm -> xpm-nox changeover was to STOP distributing a dll that depends on external X libraries and an external Xserver (which, you will note, are NOT themselves part of the standard cygwin dist). Continuing to distribute that dll kinda misses the point. Besides, the cygwin-xfree project distributes its own X-based libXpm.dll. And there are NO official packages which depend on the old X-based dll that was a part of my older xpm package. Therefore removing it breaks no cygwin dependencies -- unless you've built one yourself. And if you're experienced enough to build an app that depends on it, you are obviously experienced enough to either (a) follow the simple directions and preserve the old dll (b) if you forget, download the old package and extract the dll's by hand, or (c) rebuild your package. (a) looks pretty easy to me... > Then how long is a while? I think that OpenSSH deals with this issue in > interoperability between versions. A new feature can't break > interoperability with the previous version, but they don't keep that up > forever. So the users have to stay somewhat current, but not up to the > minute. Yes, but the OpenSSH developers have more freedom than I do. THEY OWN THE CODE. I do not. Chet changed the API. What would you have ME do? Change it back? I did what I could -- made it possible, if not idiot-proof, for the two versions to coexist. The rest is up to you. > Personally, I think one or two versions is long enough. If I am using a > package with more active development going on (a faster update rate) then I > need to update more often to stay current. Yes, but I'm not going to be here much longer. I doubt there will be another update of cygwin's noX xpm package for a LONG LONG time. Nor ncurses. Nor readline. I would call for volunteers to start taking over support for some of "my" contributions, but I know that is pointless. There are lots of folks who will complain about the way I've been supporting (or not) my contributions(*), but I seriously doubt anybody has a bad enough itch to actually step forward and take over support for those contribs personally -- at least not while I'm still here. It's SOOO much easier to complain that the current maintainer isn't doing what you want or following external release cycles fast enough, than it is to actually BECOME the maintainer yourself. I await a pleasant surprise -- but I doubt one will come... (*) these continual complaints without offers of assistance are my major pet peeve with this community. You have no idea how many off-list complaints I get. My contribs are FREE, dammit. You're free to use them as you like. You're free to fork them and do your own versions. You're NOT free to demand that I sacrifice more of my limited time to do things your way. This is not Burger King -- "you can^W CAN'T have it your way". I'm usually pretty reasonable -- but many of the demands I've been subjected to lately are not, and I've just about reached my tolerance level. --Chuck -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple