This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gary's Setup.exe v2.162


----- Original Message -----
From: "Gary R. Van Sickle" <g.r.vansickle@worldnet.att.net>
> >  After a few more games, selected "Experimental".  Now Doc
> > category "wants" to keep xml2 & xslt but *uninstall* man &
newlib-man.
>
> Yep, this I see.  I read Rob's explanation and FWICT this isn't the
intended
> behavior overall, but there's some question as to where it should be
dealt with.

Yes. I've discussed this in more detail a while back.

> Yeah, I agree, and again I believe the above comment applies.  Rob,
speaking
> from a position of relative ignorance on this particular issue, I
don't think we
> should rely on this being handled solely in setup.ini if it's possible
to do so
> in setup.exe itself, at least as a second line of defense.  Invariably
something
> will get into setup.ini not-quite-right, and setup will start
uninstalling
> people's mans, etc.

The issue is one of knowledge, and of just how the prev/curr/test split
*ought* to behave. IMO the debian (groan) model of three independent
distributions is a good basis to work off. One absolutely stable, one
with the packages that aren't bleeding edge but are not much older, and
one bleeding edge.

However I don't like the difficulties in picking and choosing between
the debian distributions, so copying that model doesn't appeal (every
say *whew*).

On the other hand, I don't like the fact that we maintainers have to
think very carefully before introducing a new package/variant because we
can trash everybody all at once - and there is no window for testing new
packages. From that angle I LOVE the concept of being able to run in
'test' as the default for setup.exe, and have everything test installed.

However: Supplying that capability means we must not promote packages
with no test: version to test, because if we do that, packages can not
be removed from test and left in prev or curr. Why would we want to do
that? Well take tetex-beta for instance. When the new tetex comes
around, it may well need some testing, so it should be test only, but
tetex-beta should no longer be available as test.

The point where the information is available to determine this is
setup.hint....

As for getting the wrong thing into setup.ini, with upset I don't think
that this is an issue. Even if this did happen, it's easier to publish a
new setup.ini than a new setup.exe - one is always updated :}.

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]