Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3C0D8535.D67735D1@ece.gatech.edu> Date: Tue, 04 Dec 2001 21:23:49 -0500 From: Charles Wilson X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jan Nieuwenhuizen CC: "Gerrit P. Haase" Subject: Re: experimental texmf packages References: <878764062 DOT 20011128173421 AT nyckelpiga DOT de> <4434079433 DOT 20011129221637 AT familiehaase DOT de> <9517228633 DOT 20011203135833 AT familiehaase DOT de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) 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. 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. 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/