Mail Archives: cygwin-apps/2001/11/11/18:12:14
Redirected to cygwin-apps, please followup there.
----- Original Message -----
From: "Brian Keener" <bkeener AT thesoftwaresource DOT com>
> >
>
> 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
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.
The current UNKNOWN bucket, IMO should be used to store the installed
package details IFF it's not listed in setup.ini.
Also local tarballs should be included, and the bucket count should be
dynamic.
> 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).
Yah, well my fix was broken, as I found when I tested.
Rob
- Raw text -