Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Subject: Re: /setup.html please read - feedback desired
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: cygwin-apps AT cygwin DOT com
In-Reply-To: <20011102195741.A31898@redhat.com>
References: <1004700277 DOT 7488 DOT 2 DOT camel AT lifelesswks>
	<3BE2E3D3 DOT 1050201 AT ece DOT gatech DOT edu> <20011102134846 DOT H26975 AT redhat DOT com>
	<1004745374 DOT 9086 DOT 77 DOT camel AT lifelesswks>  <20011102195741 DOT A31898 AT redhat DOT com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.15 (Preview Release)
Date: 03 Nov 2001 12:25:29 +1100
Message-Id: <1004750730.519.26.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 03 Nov 2001 01:29:48.0073 (UTC) FILETIME=[068FF190:01C16407]

On Sat, 2001-11-03 at 11:57, Christopher Faylor wrote:
> On Sat, Nov 03, 2001 at 10:58:58AM +1100, Robert Collins wrote:
> >
> >OTOH it's the only way we can have
> >"really stable"
> >"should be stable" and
> >"use at own risk"
> >
> >all available via setup.exe and clearly identified. Without setup.hint,
> >a single file is *assumed* to be current. IMO, that's dangerous as we
> >get more packages.
> 
> Experience has also shown that people rarely have their packages
> organized this way, however.  Instead what we've found is that people
> modify setup.hint, time passes, and then a new package is uploaded.  The
> new package doesn't show up automatically because setup.hint doesn't
> reference it and there is a period of confusion as we work things out.

Yes, the root cause of which is that setup.hint is not bound to the
individual files. That's very high on my priority list. It will also
automagically simplifly local installs. The metadata about
prev-curr-test is something that should stay outside the individual
files though, IMO. 
 
> I don't think anyone is apt to think "This is an experimental package.
> I'll just put it up on sourceware.  I'm sure the setup updater will do
> the right thing."

It would be nice if it did though, wouldn't it? 
 
> The way that packages have been updated has been -- "copy the file that
> is supposed to be the current one to sources.redhat.com".  If the version
> numbering is correct, everything just works.  That's why we have computers --
> they're really good at doing stuff like this.  They can figure out versions
> automatically without forcing someone, like me, for instance, to have to
> remember to update setup.hint.

Absolutely. My goal is to have it even easier. But there are a
significant number of steps to get there.

1) we need a package building tool that is data driven al la debian/ or
.spec.
2) We need each package file to be standalone, again like deb or rpm.
3) We need the metadata to be self repairing, or IOW, have a tool that
lets you do that 'copy' and update setup.hint (for examples sake) in one
step.

i.e. I'd like to be able to say "cygupload -current package foobar.bz2"
and have that do the right thing.

And if you have a package that is currently experimental, that no one
has complained about, then
cygupload -move package test current
would simply update setup.hint putting the current test version into
current. 

These are rough thoughts, but does the direction seem reasonable?
 
> We could insist that everyone fill out all of the version
> info in setup.hint and send dunning email when the versions don't jive
> but that just adds complication to something that is already working ok.

Agreed.
 
> When the version numbering is strange, or when you need to specify a
> test version then, of course, you need a setup.hint.  Otherwise, you
> don't.

What about when version foo requires less and vim and version bar
requires less vim cygrunsrv ?

Of course, the parser doesn't grok that yet, but lets assume that it
does. After all we are planning here...

Rob