This is the mail archive of the
mailing list for the Cygwin project.
Re: Setup snpshot bug no skip/keep
- To: cygwin-apps at cygwin dot com
- Subject: Re: Setup snpshot bug no skip/keep
- From: Christopher Faylor <cgf at redhat dot com>
- Date: Mon, 12 Nov 2001 18:40:52 -0500
- References: <200111091357.IAA29622@cs.umb.edu> <VA.email@example.com> <20011109111617.F24506@redhat.com> <VA.firstname.lastname@example.org> <042f01c16b06$67ae3350$0200a8c0@lifelesswks> <VA.email@example.com>
- Reply-to: cygwin-apps at cygwin dot com
On Mon, Nov 12, 2001 at 01:01:34PM -0500, Brian Keener wrote:
>Robert Collins wrote:
>> The problem with 4 buckets is that either 1 is a pointer to another or
>> you have to remember to change 2 whenever you change one. Both of which
>> will be annoying. When this becomes a bit more oop, this can be made
>> transparent, and then it will be easier.
>I'm confused - remove the current Info for installed and add a new bucket for
>installed in the Info structure that keeps track of Prev, Curr and Test. You
>still are only updating one installed bucket.
>> The current UNKNOWN bucket, IMO should be used to store the installed
>> package details IFF it's not listed in setup.ini.
>That works for me - I guess I just don't see why the installed Info Structure
>is separate from the info Info Structure as we discussed above. But I think in
>some earlier versions before the heavy rewrites we did use Unknown for an
>installed version not in setup.ini - at least that was the trust we used
>although we may not have used that part of the structure.
I believe that the unknown part is my invention. It's there to allow
indexing by trust levels. It's currently unused but you could shove
install in there. I am not sure why I didn't do that to begin with.
In earlier revisions all of this was stored in two unwieldy arrays that
shared a common index and the same for loop was copied to ten different
places throughout the code.
It's only slightly better now but at least with just one structure to
worry about it is easier to think about things like this.
>> Also local tarballs should be included, and the bucket count should be
I'm not sure what you mean by bucket count but, IMO, there should only
be two fixed categories "curr" and (optionally) "test". All of the
"prev"ious versions should be retrievable, not just one of them.