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
Date: Fri, 2 Nov 2001 20:46:13 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: /setup.html please read - feedback desired
Message-ID: <20011102204613.B31918@redhat.com>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT 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> <1004750730 DOT 519 DOT 26 DOT camel AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1004750730.519.26.camel@lifelesswks>
User-Agent: Mutt/1.3.21i

On Sat, Nov 03, 2001 at 12:25:29PM +1100, Robert Collins wrote:
>On Sat, 2001-11-03 at 11:57, Christopher Faylor wrote:
>> 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.

If cygupload puts the file on sources.redhat.com, then I'm in favor of
that.  If it requires that you include '-current package', then I'm
not sure that I am.

>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?

I think that putting data in setup.hint that can easily be inferred from
file names does not make sense.  You can't infer the ldesc, sdesc,
category, or requirements from the filename.  You can infer the version
number.

>>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 ?

That would qualify as a variant of "version numbering is strange".

What I'm trying to say is that I don't see any reason to require
setup.hint for the, IMO, normal cases.

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

I think that the parser should handle this and I actually think that
much or all of the setup.hint style information should be part of the
package rather than external to it.  I think we probably agree on
that.

However, if I produce a cygwin-1.3.59-1.tar.bz2 with no package info,
I still think that 'upset' (the cygwin setup.ini updater) should
be able to infer the info.

cgf