X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,TW_YG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Achim Gratz Subject: Re: cygport/setup questions Date: Wed, 14 Mar 2012 20:33:18 +0100 Lines: 80 Message-ID: <87r4wvgept.fsf@Rainer.invalid> References: <87mx7kutlc DOT fsf AT Rainer DOT invalid> <4F5FF2ED DOT 6010905 AT users DOT sourceforge DOT net> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com "Yaakov (Cygwin/X)" writes: > On 2012-03-13 15:35, Achim Gratz wrote: >> 1. Is there some way to specify CPAN bundles rather than individual >> packages in the .cygport file? I don't mind if I'll get a tar.bz for >> each package the bundle pulls in, I just want to limit the number of >> packages visible during setup. > > Not simply. A CPAN bundle doesn't contain more than a pod file; it > relies on CPAN to install whatever modules it requires. There is also > no guarantee that a given module is not a member of more than one > bundle, which would result in file clobbering, and setup.exe does not > handle that gracefully. OK, so I just have to mass-generate a load of cygport packages and then maybe bundle them into an umbrella package with no content of its own, but make that dependent on all the others so I don't have to specify all of them for installation. Fair enough, just not as easy as I hoped. > If you just want to make it easier for users to install a CPAN bundle, > I suggest packaging each module individually, then have the bundle > package depend on the other modules. Most users will never see the chooser window anyway, so it's probably OK either way. >> 2. How should I name a package that I patch locally? Can I use a >> non-numerical RELEASE, I'd like to avoid name clashes between the patched >> package and later official releases. > > IIRC, release must begin with a digit. Perhaps a 0.x release number > would work, I haven't tried it. I've had to try it today, and it seems that appending something alphanumeric (like -2p1 for the first patch on release 2) is OK with setup.exe (don't know yet what genini thinks of that, though). >> For the patch itself, I just edit the sources, that cygport is going to >> build from. Do I have to (re-)generate the src.patch before each build >> or is cygport doing that by itself? > > Once I've created a patch, I copy that patch alongside the .cygport, > give it a meaningful name, then add it to PATCH_URI. That makes it > easier to carry the patch forward from one version/release to another. You've lost me here, where does that PATCH_URI you are talking about belong? The packages I've looked at had at most two patch files (for the source and for cygwin specific additions) that are seemingly used automagically. Not that I looked at a lot of packages... >> 3. How can I make sure that local customizations are always done after >> all "real" package installs? It seems there is a hidden category >> _PostInstallLast that may or may not do that. Also, I might need to >> control the order of post-install scripts, they seem to be run in >> alphabetical order, can I rely on that? > > What local customizations do you want? Not sure yet, but basically anything that can't be solved by simply dropping a file in the right place and that isn't associated directly with a package being installed or de-installed. >> 4. From the testing results so far, I will always have to do a rebaseall >> and perlrebase. Can I do this from setup.exe (after customization) or >> does it have to be a separate process after setup.exe has finished? > > The eventual goal is to integrate this into setup.exe, but currently > these need to be run manually after installation/update. I think I can fake it with the current setup.exe (I already install the snapshots this way). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple