Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Fri, 09 Nov 2001 12:51:34 EST
To: cygwin AT cygwin DOT com
Subject: Re: Setup snpshot bug no skip/keep
X-Mailer: Virtual Access by Atlantic Coast PLC, http://www.atlantic-coast.com/va
Message-Id: <VA.000009ca.00eab648@thesoftwaresource.com>
From: Brian Keener <bkeener AT thesoftwaresource DOT com>
Reply-To: bkeener AT thesoftwaresource DOT com
In-Reply-To: <20011109111617.F24506@redhat.com>
References: <200111091357 DOT IAA29622 AT cs DOT umb DOT edu> <VA DOT 000009c5 DOT 0059ec5d AT thesoftwaresource DOT com> <20011109111617 DOT F24506 AT redhat DOT com>

Christopher Faylor wrote:
> Info *installed;      /* Info on installed package */
>   trusts installed_ix;  /* Index into info array for currently installed package */
>   excludes exclude;     /* true if this package should be excluded */
> 
>   /* The reason for this weird layout is to allow for loops that scan either
>      the info array, based on trust value or the infoscan array based on a pointer,
>      looking for a particular version. */
>   Info info[1];                 /* First element.  Intentionally allocated prior
>                                    to infoscan */
>   Info infoscan[NTRUST - 1];    /* +1 for TRUST_UNKNOWN */
>   Info infoend[0];              /* end marker */
> }
>

Sure I noticed packages are of type info which is itself a structure with all the 
pertinent info.  I also notice that the *installed* structure is a different 
substructure from the selectable packages substructure *info*.  Under a normal 
situation this is not a problem (and probably isn't for you more experienced coders) 
but for me it was.  I will try to explain:  In info we have bucket/slot (probably not 
the right term but go with me here) 0 which is Prev and bucket 1 is Current and 
bucket 2 is Test or something like that and then we have a separate structure for 
installed.  Now when installed is one of Prev, Curr or Test all is wonderful and the 
enum we use to step through the Trusts works great.  But if installed is outdated you 
now get a lot of extraneous code (at least I thought so) because installed is not one 
of Prev, Curr, and Test and yet you want the option to keep the installed available 
just like *keep*ing the Prev, Curr, or Test is available.  In my attempts it was 
tough and created I lot of unnecessary code.  My contention is that the structure 
should be bucket 0 is prev, bucket 1 is current, bucket 2 is test and bucket 3 is 
installed.  Basically have 4 versions instead of 3 and two of them may or may not be 
the same.  This also makes it easier for the actions which are based on the trusts to 
step through prev, curr, test, keep, redownload, reinstall, source, redownload 
sources and reinstall sources and whatever in my opinion.

I am sure you guys handled this no sweat - since I see Robert has posted a fix for 
the skip/keep anyways and I did not mean to imply it was impossible to fix, just 
thought I thought a slight structure change would make it not so cumbersome (with my 
skills).

Now that I have made this long dissertation I hope that it *was* the fact that the 
installed structure was there as well as the info structure.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/