experimental texmf packages
Wed Dec 5 15:35:00 GMT 2001
@%!@#$ AT&T@home smtp server.... it lost my reply to this message, so
this is try #2...
Jan Nieuwenhuizen wrote:
> 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
I'm not sure I understand. It wasn't that you needed to provide a
reverse patch, but that you need to provide the PATCH so that users
could 'unpatch' using 'patch -R'. The only wackiness was the assertion
that the downloaded source be *already patched*. So, you get
'pre-patched source' + 'the patch that was used to make it that way',
instead of 'pristine source' + 'the patch you must apply'.
> > You need to understand where that requirement came from: protective
> > action against maintainers who flake out.
> I understand this must be avoided at all cost.
> > 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.
It's not supposed to be a backward patch; see above.
> > 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 :-)
Well, setup can't yet do what you're implying. But eventually...
> > there is no iron clad, my-way-or-the-highway standard, but agreement on
> > a number of principles:
> > 1) official, unmodified source code should be provided
> > 2) with a diff (or multiple diffs) that are used to turn the official
> > source into cygwin source
> > 3) there should be some sort of automated script -- shell script,
> > external makefile, *something*, to drive the entire cygwin build
> I'm not sure I understand. Have the 1-diff,reversed diff, pre-patched
> -src requirements been dropped?
I think so.
> How about an example dummy package like this?
Okay. go here:
There are five different versions, each of which demonstrates a
different proposal. After cgf's "intervention" I pretty much settled on
something like #5 for "my" packages, and that is what the "official"
mktemp package at sourceware uses. Also cygutils and others.
> Now every package should contain a build script. Isn't that a step
> backwards in the evolution?
Not really. It's a lot better than "here are some instructions in this
custom cygwin README -- no, not the official README; look at the custom
one under /usr/doc/Cygwin/. Follow the instructions
manually...configure with *these* options, 'make install' with *those*
options, etc". At least a buildscript is automated. Also, MANY
packages don't even contain instructions (beyond what the primary
distribution site says or includes in the pristine source). So we don't
know HOW the maintainer configured it...
pop quiz: what are the current configure flags used to build gcc?
Anyone? Anyone? Bueller? (no, Chris, you're not allowed to answer..)
Methinks a build script -- of whatever flavor, sh, make, dpkg, spec --
is a step forward for us.
> You'd want a central tool(set) to do the
> building and packaging, and package specific scripts/makefile
Well, that's what Robert is pushing. But IMO we shouldn't try to
reinvent THAT wheel (the package building/packing functionality that
other all-in-one package management solutions provide). In other words,
setup.exe shouldn't become the rpm.exe of cygwin, complete with 'setup
-ba myspecfile'. Bleagh. We needn't write another tool for this task,
like "cygpack" or something, with yet another grammar to parse and
learn, to drive autobuilds.
There are just too many corner cases and exceptions to deal with. The
dpkg folk and the rpm folk have already solved (mostly) those issues;
when we're ready we should just USE those tools. "When we're ready" ==
when setup.exe can install the binary packages created by them. Which
is not yet.
I described many of the corner cases and exceptions in that other thread
-- probably because most of the things I have chosen to port/maintain
ARE corner cases, so I'm intimately familiar with the problems (or maybe
I'm just not a very good porter, and if I were better at it, I'd've
forced my square-peg-packages into some sort of standardized,
non-corner-case round hole by now...)
Anyway, UNTIL we're ready to make a complete jump over to rpm or dpkg or
whatever, there's no point in developing additional tools. Custom build
scripts, written in the package maintainer's language of choice -- sh,
perl, make-rules, etc -- provide the *maintainer* with the flexibility
needed to deal with the corner cases (if any) yet allow
newbie-developers to download and build easily. And we aren't
autocratically forcing all maintainers to "Do it THIS way or go home."
Which is good -- at least until we adopt rpm or dpkg or something.
> > But you gloss over the *reasons* it didn't catch on:
> > 1) There was no true NATIVE port, so you couldn't use rpm to install
> > cygwin itself.
> That is a real problem. But it solved the cross-building, the
> tarball/patch issue, binary packaging, dependencies, pre/post
> install/remove scripts for me.
And it solved the perl add-on module problem for me. But once I
relinquished maintaining perl, I had no further need of rpm. Or
desire. It's the whole "scratch your own itch" thing. (Side note: I
*am* considering using the new -- !!not yet ready for public
consumption!! -- libtool to port berk db as a test case...)
> > 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.
That's the thing -- Chris has been offering webspace if folks needed
it. BUT, you don't even NEED webspace to port a package. Just port it,
promise to maintain it, and upload it to sourceware.
> But I did implement
> .patch.rpm's (supply pristine source yourself) to work around that,
> and put it up here (where it sits and rots):
This is probably why it rots (same as my rpm port): "/b20/". I figure
anything with "b20" in the name is so old and unmaintained it probably
doesn't work on newer cygwins. So I just skip over stuff like that.
> Also, while I am/was willing to help out the Cygwin project, I'd
> rather work on LilyPond than reinvent packaging/do porting.
That's fine. Please continue -- scratch your own itch. But folks
shouldn't complain when nobody wants to scratch their itch FOR them,
like provide/maintain rpm.
> hoped people to be interested, discuss and maybe take over what I
> tried to start, but nothing much happened, then.
> > > and I built a set of cross-build scripts
> > > from the .spec shell-snippets.
> > that's a neat idea. Can I see?
> Sure (it's been posted to the cygwin list a couple of times, but as
> there where no reactions, I decided not to spam the list any
> further). Find the latest here:
I'll take a look this weekend.
> > However, "rpm-like" is still on the table in
> > the sense of:
> > 1) provide pristine source
> > 2) provide the patches
> > 3) provide "something" to autodrive the build (shellscript+sh.exe,
> > debian.rules+dpkg, spec+rpm, whatever)
> > 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?
Sounds like Dario's CART. Except I think Dario build a special
cygwin1.dll with a different name and shared memory area, and linked his
CART-rpm and CART-sh to THAT. That way, he could run the installer
tools to install the REAL cygwin and the REAL rpm over in the REAL
location. Then the CART deleted itself.
> > (This sidesteps the question about "where do you put the package
> > management database for a native windows port of rpm/dpkg/whatever?"
> > You can't put it in /var/lib/rpm/ (because cygwin installation will
> > manipulate the mount table; you don't know where /var will BE until
> > after the installation is finished).
> 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?
See Robert's post.
> What if you'd only allow setup.exe to choose the cygwin root for the
> first installation?
Ditto (and ignored).
> > Of all the let's-use-rpm proposals, Dario's makes the most sense --
> > although Robert's eventual plan for setup.exe ain't bad either.
Ditto (and ignored).
> Ok, so I missed not only this discussions, but also actual code.
> Ignore my rpm questions above, I'll have a look into these two
> alternatives first.
> > <rant>
> > Jan, next time try CONTRIBUTING to the discussion, instead of calling
> > the result silly after the fact.
> > </rant>
> 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.
It was probably a timing thing (that and everybody hates these packaging
debates. They're really counterproductive -- a lot of noise, and nobody
works on ACTUAL stuff like fixing cygwin bugs or porting new packages
for a while, and then it's over and nothing's been decided...
Anyway, "some months ago" we were all desperately trying to get
cygwin-1.3.4/5 out the door, and get the new setup.exe with categories
online, and everybody probably said, "Nice idea. Can't think about that
now. Maybe later..."
> Being only involved occasionally, and going
> through the archives directly, I didn't find out about the apps list
> (and open membership) until recently...
Yep, packaging and setup DEVELOPMENT happen on cygwin-apps. (setup bug
reports, and "wouldn't it be nice if..." belongs on cygwin@ though)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
More information about the Cygwin