On Sun, Nov 11, 2001 at 04:09:47PM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <[EMAIL PROTECTED]>
>> >There are some things I believe we should be able to do with
>> >/etc/setup...
>> >1) Detect cross-package conflicts. Say foo and bar both contain
>> >/usr/bin/ld.exe.
>> >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
>approach --
>> >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
>working
>> on this but maybe this is an important enough goal that it is worth
>doing
>> ASAP.
>
>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"
discussion?

>> 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
specific code.

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,
Robert?

Well...  This is different because, er, um.

Gee, look at the time.  Gotta go.

cgf

Reply via email to