This is the mail archive of the
mailing list for the Cygwin project.
Re: Move zlib up one level?
On Sun, Nov 11, 2001 at 04:09:47PM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <email@example.com>
>> >There are some things I believe we should be able to do with
>> >1) Detect cross-package conflicts. Say foo and bar both contain
>> >2) The lst files are currently gz' files, I think it would be good to
>> >change to using bz2 in the future.
>> >Doing the 1st one really requires a more database orientated
>> >long term of course.
>> Right. But in the meantime we have a huge user base who can't easily
>> figure out what packages they have installed.
>Perhaps a new view in setup - categories/full/partial/installed ?
Yes. That would be nice.
>> Absolutely. I really hate this but I was doing it the wrong way for 1.3.5.
>> I am optimistically thinking that there won't be a new cygwin release for
>> a while after that and I wanted to get something that works into 1.3.5.
>Makes sense. Hopefully the daemon will go in immedaitely post 1.3.5, and
>that will need a little ironing out I'm sure.
>> I also didn't want to be pulling things apart while you are actively
>> on this but maybe this is an important enough goal that it is worth
>As long as you're happy to rework cygcheck twice :].
Yep. The reworking will just be pulling out chunks of code.
>> 1) setup.exe is currently a windows app so it can't write
>> to the >console.
>That's a small problem :}.
Place your bets now. Will we restart the "it must be possible"
>> 2) Cygcheck should really be the one stop place for all debugging
>> output so, at the very least, cygcheck would have to call a
>> 'dump capable' setup.exe to get its output but, that wouldn't
>> be useful for debugging cases where setup.exe wasn't available.
>I think cygcheck should have the functionality built in statically,
>just the source shouldn't be split.
Yep. That's why I mentioned this.
As it is now, cygcheck was actually showing its age since some parts of
its registry parsing weren't up-to-date with cygwin. I've fixed that
but (Captain Kirk voice):
For. How. Long?
Ideally, we should be actually able to craft a library that even the
Cygwin DLL can use as long as the library doesn't use any MSVCRT
Hmm. I like this idea better all of the time. I wonder how much of
the cygwin code can be pulled into a reusable library.
Although, I just told you not to use cygwin code in setup.exe, didn't I,
Well... This is different because, er, um.
Gee, look at the time. Gotta go.