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
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <00d501c17d93$1936c990$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>,
   "Jan Nieuwenhuizen" <janneke AT gnu DOT org>
Cc: "Gerrit P. Haase" <cygwin AT cygwin DOT com>
References: <m3bshtmxhb DOT fsf AT appel DOT lilypond DOT org><878764062 DOT 20011128173421 AT nyckelpiga DOT de><m37ks9lgxi DOT fsf AT appel DOT lilypond DOT org><4434079433 DOT 20011129221637 AT familiehaase DOT de><m3oflgy98n DOT fsf AT appel DOT lilypond DOT org><9517228633 DOT 20011203135833 AT familiehaase DOT de><m3lmgkwgeu DOT fsf AT appel DOT lilypond DOT org> <3C0D8535 DOT D67735D1 AT ece DOT gatech DOT edu> <m33d2pam3l DOT fsf AT appel DOT lilypond DOT org>
Subject: Re: experimental texmf packages
Date: Thu, 6 Dec 2001 00:45:26 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 05 Dec 2001 13:45:28.0157 (UTC) FILETIME=[195240D0:01C17D93]

----- Original Message -----
From: "Jan Nieuwenhuizen" <janneke AT gnu DOT org>
>
> Well, I still thought it was silly to have identical forward and
> backward patches, when we have a patch -R flag.  Normal mode of
> operation is to (apply and) supply forward patches; now my (and
> everyone else's packaging procedure) I must be rewritten to do unpack,
> rename -> .orig, patch, run diff from .orig tree.  Or, be hacked to
> try to determine the direction of the patch before applying, but

Well to diff you always need two trees, the orig and the working tree.
So having your pristine source in .orig doesn't seem hard to me :}.

> > So, we said "provide prepatched source" -- because people wanted to
> > just unpack, configure, make -- but also "provide the diff between
> > your source and the official version".
>
> Sure, but I don't see any advantage in reversed patches.

With patches that remove the cygwin code from the source in a tarball,
you need a separate tarball + a separate patch for each -1, -2, -3 of a
given upstream source tarball.

With patches that add the cygwin code to the source in a tarball, you
need a single tarball for the given upstream source tarball + a single
patch for each of the -1 -2 -3 releases. So this is more bandwidth
efficient for everyone. Does setup.exe support this now? No. Will it?
Yes.

> > Yes, it's a pain.  Yes, there are better ways.  But silly? no.  (I
think
> > the silly part was insisting that the source code be PRE-patched.
>
> Yes, I think that requirement is silly too.  Because people will be
> using a download cache, the pristine source is there too.  Build
> environments now hold pristine sources, patched sources, and patches
> in both directions.  But, whatever gets you going :-)

Build environments to recreate a -src package need
a) pristine source TARBALL.
b) patch for current -x version
c) extracted and patched working dir.

I don't see where patchs in both directions come in.

> I'm not sure I understand.  Have the 1-diff,reversed diff, pre-patched
> -src requirements been dropped?  Currently, I dist the pristine

the pre-patch -src requirement has been. See
http://www.cygwin.com/setup.html. No mention of a prepatched source
tarball is made at all.

> Is this sort of what it should be now:
>
>     $ tar xzf foo-1.1-1-src.tar.gz
>     $ ls foo-1.1-1-src
>     foo-1.1-1-src/foo-1.1.tar.gz  # pristine src
yes
>     foo-1.1-1-src/foo-1.1-1.patch # forward diff
yes
>     foo-1.1-1-src/other.patch
what's this?

>
>     $ cat foo-1.1-1-src/doit.sh
>     #!/bin/bash
>     set -e
>     tar xzf foo-1.1.tar.gz
>     mv foo-1.1 foo-1.1-1

Not sure why you're bothering to rename this.

>     cd foo-1.1-1
>     patch -p1 < ../other.patch
>     patch -p1 < ../foo-1.1-1.patch
>     autoconf

autoheader + automake etc etc as needed.

>     ./configure --prefix=/usr
>     make
>     make install prefix=/tmp/foo-root/usr
>     cd /tmp/foo-root
>     tar czf /usr/src/foo-1.1-1.tar.gz *
>
> How about an example dummy package like this?

Chuck went around this with mktemp. It looks similar, but you don't need
to use /tmp, just `pwd`/=install will do.

> Now every package should contain a build script.  Isn't that a step
> backwards in the evolution?  You'd want a central tool(set) to do the
> building and packaging, and package specific scripts/makefile
> snippets.

Yep, like rpm/deb have. But, setup can't read files from either of those
formats (yet).

> >   2) Nobody, and I mean NOBODY, has followed thru on porting,
packaging,
> > and maintaining the berkeley-db and rpm packages as official,
> > cygwin-mirror-system distributed packages (surely that's the FIRST
step
> > before attempting to use rpm as the be-all and end-all package
> > management application for cygwin?  PROVIDE it and maintain an
official
> > port?)
>
> I didn't have the webspace to do that.  But I did implement

Grr. Thats the whole point. Chris has repeatedly offered web space to
interested parties. The WHOLE point is that it should be _here_ for it
to catch on. Then there is no need for any single individual to generate
the whole list of pacakges, or

...
> Also, while I am/was willing to help out the Cygwin project, I'd
> rather work on LilyPond than reinvent packaging/do porting.  I
> hoped people to be interested, discuss and maybe take over what I
> tried to start, but nothing much happened, then.

do porting. So the point is that if RPM had been contributed, and you
maintain *just that one package* as an official package (Hey, Chuck this
goes for you too :}) then there is a chance that it could have caught
on, and maybe the open file issue would have had a workaround
implemented in rpm (which is possible, just non-trivial BTW).

> > a) source code autobuilding and packing
> > b) installation and unpacking
> >
> > Part A assumes you already have a working cygwin development
environment
> > installed on your machine. Part B must be doable on a "virgin"
> > system.
> > Thus, the installer-unpacker must NOT rely on cygwin.
>
> What I did, using rpm, was provide a rpm-x.y.z.bin.tar.gz, including
> necessary libs.  If setup.exe can't run rpm, it gets and untars the
> tarball.  After that, it installs/upgrades the cygwin, rpm, zlib
> .rpm's.  Of course, that's the easy part.  But it wouldn't be hard to
> let setup.exe handle the final placment of any binaries that were in
> use during the rpm phase.  Is that too kludgy?

Potentially. What you have to do is group a set of related files from
multiple packages that solve a dependency issue where *any one* of the
files cannot be installed due to open file issues, schedule those for
copy-after-not-in-use, and the trigger that, and then return to that
exact internal rpm state, and start running the postinstall scripts etc
for that group of files.

> Ok, so, a native port, that should be more feasible with the current
> state of mingw(?), would pose other problems.  But these seem even
> easier to solve?

That hasn't changed - mingw doesn't aim for posix support. A native port
is purely a matter of effort and creating win32 code that does what rpm
does.

> What if you'd only allow setup.exe to choose the cygwin root for the
> first installation?

I'm not sure what that does other than cripple users who want to move
cygwin around on their hard drive.

> You're right to rant here, because my mail really was a rant too, I'm
> sorry.  But I always try to put code first, and then start a
> discussion.  In this case, I've presented rpm stuff, my cross-build
> scripts, and some months ago a patch for a setup.exe postremove
> feature.  Maybe it was bad timing, maybe my code was just too bad, but
> on each of these occasions I got so little sensible feedback if any at
> all.  That turned me off a bit.

BTW: can you freshed up your postremove patch? I'd like that to be
included in setup.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/