Re: new 'temp' directory in CVS cinstall contains dependency WIP

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
> I posted a URL to update-setup recently, possibly in cygwin-apps.
>
> I'm not sure why you are referring to it, though.  The setup.ini that
> update-setup produces is the same old setup.ini that is currently in
> use.  The "rh" script works on it to produce a categorized version.

To check my other assumptions.

> No.  I just wrote the script to provide a baseline that we could use
> going forward.  I did want it to be as robust as possible so that I
> could use it to regenerate things in case of a catastrophe but I don't
> think that it will ever be used again after this initial go around.

Cool. I got confused ("Why is this script needed, I thought we settled
categories etc a month or two back... hmm Chris must be setting this up
for maintenance.")...

> I wasn't trying to open up a discussion of where the data would be
> stored.  That ship has sailed.  I sent a message about this weeks
> ago which had no discussion, IIRC.

Uhm I recall the discussion when you created the new ini files
initially, and there was a flood of messages with a title similar to
"updated ini file with categories and depenedencies". I'm sure that
Chuck and I responded, and Corinna was in there. (while I only maintain
1 package, Chucks response covers nearly all the 'net contributors' :]).

> >Well my good idea is basically to delegate the responsibility and
> >authority to maintaing the category and depenency stuff to the
> >maintainers. IMO that solves the problem in one hit. We allow 1 week
for
> >all the maintainers to create setup.hint files with category and
> >requires lines. At the end of the week we put up the new setup.exe.
>
> Or, the maintainers could change the setup.ini file as I suggested.

I don't particuluarly like that idea. IMO (based on the debian approach)
the setup.ini has no important data in-and-of itself. Still in
functional terms, yes that would work. One nice advantage of only
altering the setup.hint files is that any catastrophe that occurs to
setup.ini will have 0 impact. Just delete and regenerate from the hint
files.

> I don't see that it makes a big difference except that I can delay
> adding the parsing of extra fields in update-setup.  If you create
> a setup.hint file in contrib/latest with the new fields now it is
> possible that update-setup will croak.

Yes.

Index: update-setup
===================================================================
RCS file: /cvs/cygwin/htdocs/update-setup,v
retrieving revision 1.11
diff -u -p -r1.11 update-setup
--- update-setup        2001/09/17 20:23:08     1.11
+++ update-setup        2001/09/23 13:50:34
@@ -143,6 +143,12 @@ while (<F>) {
        if ($type eq "ldesc") {
            $ldesc{$package} = $version;
        }
+       if ($type eq "category") {
+           $category{$package} = $version;
+       }
+       if ($type eq "requires") {
+           $requires{$package} = $version;
+       }
     }
     close (S);

@@ -173,6 +179,8 @@ for $p (sort keys %versions) {
     print "@ $p\n";
     print "sdesc: ", quoted($sdesc{$p}), "\n" if $sdesc{$p};
     print "ldesc: ", quoted($ldesc{$p}), "\n" if $ldesc{$p};
+    print "category: ", quoted($category{$p}), "\n" if $category{$p};
+    print "requires: ", quoted($requires{$p}), "\n" if $requires{$p};
     &one_version("", "curr");
     &one_version("[prev]\n", "prev");
     &one_version("[test]\n", "test");

> Since I've gotten almost no response to my request that people inspect
> the dependencies in setup.ini I think we'll actually sail by the
> week mark very soon, anyway.

I _really_ think the thing to do is pin it on the maintainers. If we
sail past the week, release!. I mailed back in the prior discussion on
squid. I'm happy with the way it looks now.

> I actually expected that almost no one would respond and this is
> exactly why I wrote the script.  Otherwise, I'd be sending out
> "Please update your package info!"  "Really!"  "Come on!" mail
> for the next four weeks and would just end up doing it myself.

Again, I'd take a fairly simple but brutal here. If the maintainer
doesn't respond, it's 'obviously' correct. If, after the release there
are complaints, and the maintainer cannot be found, and noone else steps
up, pull the package. It's not your task (to avoid the overloaded term
"job") to do what us maintainers are meant to do.

As far as I can see, any other approach will end up with you pulling
your hair out by the roots, and I don't think that would be a pretty
sight.

Rob