Mail Archives: cygwin/2001/12/04/21:27:16
Jan Nieuwenhuizen wrote:
> Thanks. I know about that page; but I'm not sure about the status of
> all individual items; notably the absolute silly reversed-patch
> requirement.
Silly? no. Difficult and painful, prompting questions like "surely
there is a better way"? yes.
You need to understand where that requirement came from: protective
action against maintainers who flake out. I'm going to pick on Mumit
Khan, here, who is a great guy and has done a lot for cygwin over the
years -- but who, for personal reasons, dropped off the planet for about
a year (he's back now). Before his departure, Mumit was also the
de-facto gcc-on-cygwin (actually, egcs-on-cygwin) maintainer.
For a long time, Mumit was the only person who really understood and
knew about all of the hacks to egcs/gcc that were necessary for "proper"
operation under cygwin. He packaged up "replacement" gcc's and
everybody happily downloaded and used them. He also provided source,
but it was his own modified devel tree. When he left, we were stuck for
a LONG time without an up-to-date gcc. I mean, you COULD download the
original source for the version that Mumit forked from, download his
source, do the diff, go thru it line by line to determine what was
necessary to carry forward, and then apply the result to the new version
of the official gcc source...
painful. It took cgf and dj some months to winnow thru it all. Right
about that time, we were trying to come up with a packaging
"standard"...and were feeling quite stung by the gcc experience. We did
NOT want that sort of thing to happen again. 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".
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.
Surely folks can patch it themselves if given the diff...)
> I've seen some discussion, but no conclusion or
> agreement...
Well, it sorta ended like this: CGF: "Stop bickering. This is NOT that
big a deal; we have more important things to worry about. Whatever is
reasonable, is okay. And we don't really need just ONE standard."
(okay, I'm paraphrasing). But basically, I think we ended up with:
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
5) setup will unpack stuff under /usr/src (for now; later setup may
unpack -src archives into a user-selected destination)
4) there is no need to go back and repackage everything that's already
in existence just to make the -src package "conform" to these
principles. Redo -src packaging in the normal course of updates.
That's it. (right guys? we all pretty much agree with ^^^ at least,
right?)
> I've tried to stay within the spirit of it, the packages should now be
> mostly complient. (Fwiw, I think it's totally silly to reinvent
> package management for the umpteenth time.
Yes. But unavoidable, given the realities...
> Three years ago, I ported
> RPM
You did that? I thought *I* did that (cygutils, perl-5.005 modules, mid
1998). I think it's silly for people to re-port the same applications
for the umpteenth time... :->
> and (cross-)built all my Cygwin (lilypond-support) packages as
> RPMS. RPM didn't catch on,
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.
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?)
there's been a lot of talk, and "wouldn't it be nice" and "those guys
at project heavymoon..." or "you know, there's a `cygwin-rpm' project at
sourceforge...". But NOBODY has stepped forward HERE, on THIS list, to
provide it as an OFFICIAL, sourceware-distributed cygwin package! It's
funny, but the folks who yell loudest about "why don't you just use rpm
for pkg management" are also the ones who scatter like cockroaches when
somebody flips on the light and says "great, please package up a port so
we can ease into using rpm/dpkg/whatever". Or, they would rather fork
the entire cygwin project and set up their own page duplicating all of
cygwin under the "rpm" (or "dpkg") paradigm. (project heavymoon,
cygwin-rpm AT sourceware, debian-w32, etc) -- but they always start off
with "first install cygwin using setup.exe, and then..." (MAN, that
point #1 is a doozy...)
Dario Alcocer finessed point #1 by using a minicygwin distribution
(that included only ash, rpm, db, and cygwin1.dll itself; he called it
the "cygwin application runtime" or CART) to install the REAL cygwin.
See http://www.helixdigital.com/~alcocer/rpm-installer/ for a design
document. Back in September, I heard that Dario had an ISO image ready
for test, but I never saw a URL for it...
However, unless Dario was volunteering to support official db and rpm
packages for cygwin (I don't think he was, although he "knows" how --
Dario is the ghostscript package maintainer) this still doesn't address
point #2...
> and I built a set of cross-build scripts
> from the .spec shell-snippets.
that's a neat idea. Can I see?
> But now discussions on cygwin-apps
> mention 'RPM-like' behaviour and layout. Sigh.)
Well, except that it was decided that going halfway to rpm-style layout
without ACTUALLY using rpm was kinda silly. (I can say that; it was my
idea that got shot down). 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)
Sure. All modern package management schemes are going to look SOMETHING
like that. The difference we have on the cygwin platform is that we've
bifurcated the traditional package/system management tasks into two
groups (out of necessity, see point 1 above):
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 (unless you jump
thru hoops a-la' Dario). That's setup.exe. Nobody is proposing that
setup.exe take over part A. THAT's the primary difference between us
and the umpteen other pkg-management systems. And it's driven by
necessity: chicken-and-egg. The existing GOOD pkg-management systems
haven't been ported to the native windows API and therefore require
cygwin1.dll -- but windows won't let you replace a file that is
currently in use, so you can't use *cygwin* ports to install or update
cygwin1.dll 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). But if you're relying on "cygwin
will do thus-and-so, so let's put the database HERE" -- then that's not
really a NATIVE port of rpm -- it's a crossbreed.)
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. He's
ripped out the guts of setup, made everything stream-based, so now we
can plug in different backends -- eventually. Like cpio, rpm, etc.
Still a lot of work left, tho. Note that the two examples I'm praising
involve actual, roll-up-your-sleeves WORK -- both Robert and Dario put
effort into their proposal and showed something concrete. Not armchair
quarterbacking or sideline sniping.
<rant>
Jan, next time try CONTRIBUTING to the discussion, instead of calling
the result silly after the fact. (I refer here to the "-src packaging
standard" discussion on cygwin-apps several weeks ago) You act as if
you have all the answers, and merely observed us morons flailing our way
toward redoing what you knew all along we should do. Fine, I'll admit
that I don't know everything -- and I'd sure love to see your
contributions to those discussions (WHILE they are ongoing) since you're
so all-wise. Anybody can carp after the fact and call the result --
acheived without their input -- "silly". Put your effort where your
mouth is before you criticize. I put up on the web four or five
EXAMPLES of each packaging proposal so that folks could test and
evaluate them. Where were you? Oh, yeah -- sighing about our
reinventing package management for the umpteenth time...but not
contributing to the discussion.
</rant>
I appreciate your efforts w.r.t. tetex-*; please don't take the above
rant as criticism of THOSE contributions. You've actually contributed
to cygwin as a whole, there; I'm just upset about the sideline criticism
of the packaging discussions, since we obviously could have benefited
from some additional input -- but got very little. It was mostly a
dialogue between Robert and I, and I'm still a little disappointed at
the lack of wider participation in that discussion.
--Chuck
--
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/
- Raw text -