Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Subject: Re: RFC: Allowing cygwin setup to patch up old versions
From: Robert Collins <rbcollins AT cygwin DOT com>
To: chris <caj AT cs DOT york DOT ac DOT uk>
Cc: cygwin AT cygwin DOT com
In-Reply-To: <bgam88$2pq$1@main.gmane.org>
References: <bgam88$2pq$1 AT main DOT gmane DOT org>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PEqIInVF0lLWp87h+YqJ"
Message-Id: <1059644155.15989.40.camel@lifelesswks>
Mime-Version: 1.0
Date: 31 Jul 2003 19:35:55 +1000

--=-PEqIInVF0lLWp87h+YqJ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2003-07-31 at 19:11, chris wrote:

> I would like to try to pull this into the main cygwin setup tree, and=20
> was wondering if there is any kind of document that specifies exactly=20
> how files will be set out on both the computer and the server, of if I=20
> should just parse the code and see where it says files live? :)
>=20
> Any comments (even "Someone is already working on that" or "Go away and=20
> stop bothering us") much appresiated! :)

Ok, a few thoughts:
1) You'll want to decorate the download logic to have the patching occur
seamlessly.
2) It's a nice concept, but you'll also want to generate the patch files
automatically, so that maintainers don't need to think about this. A
perl fragment is probably what Chris needs to integrate into the web
server update scripts, but this is probably the last piece of the
puzzle.
3) As to file locations: put the patches in the same dir as the files.
Extend setup.ini (and the lexer/parser in inilex.l and iniparse.y, + the
IniBuilder interface) to recognize your patch metadata... as part of the
packageversion information. Do NOT put the patch metadata in a separate
file - that would extend the cost to calculate what needs downloading
hugely. I suggest that you store the patch in the packageversion object
it patches to, allowing trivial reverse iteration to calculate the
shortest path (as we know it's a DAG, we can cheat).

Lastly, follow the contributor Guidelines I've posted links to recently,
and be sure to submit patches against HEAD.

If you'd like a CVS branch to work on, that can be arranged.

Cheers,
Rob

--=20
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
---

--=-PEqIInVF0lLWp87h+YqJ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/KOL7I5+kQ8LJcoIRAu5pAKCDAyqm617UD3p9RlaIfOQQKU9VzACgiUq+
uagPGTMHp6vBk8Jaht0sTJg=
=Kp6r
-----END PGP SIGNATURE-----

--=-PEqIInVF0lLWp87h+YqJ--