Re: cygport/setup questions
Yaakov (Cygwin/X) yselkow...@users.sourceforge.net 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
Re: cygport/setup questions
On 2012-03-14 14:33, Achim Gratz wrote: 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. PATCH_URI is a list of one or more patches which are applied to the source immediately after unpacking. Like SRC_URI, you can specify remote URIs (e.g. from other distros) or just a filename to indicate a patch saved alongside the .cygport file. Using PATCH_URI with local patches makes it easier to carry patches forward from one release to another. Not that I looked at a lot of packages... Ports git http://cygwin-ports.git.sourceforge.net/ provides a wide variety of packages to learn from. Yaakov -- 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
Re: cygport/setup questions
Yaakov (Cygwin/X) yselkow...@users.sourceforge.net writes: On 2012-03-14 14:33, Achim Gratz wrote: PATCH_URI is a list of one or more patches which are applied to the source immediately after unpacking. Like SRC_URI, you can specify remote URIs (e.g. from other distros) or just a filename to indicate a patch saved alongside the .cygport file. Using PATCH_URI with local patches makes it easier to carry patches forward from one release to another. Again, where do I put PATCH_URI and what is the format? I suppose this should be someplace in the .cygport file? The README that is linked from the cygwin site doesn't mention it... http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/cygport/trunk/README Do you have a link to the complete documentation perchance? http://cygwin-ports.git.sourceforge.net/ A! Much better, I found a package that uses it. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
Re: cygport/setup questions
On 2012-03-14 15:20, Achim Gratz wrote: Again, where do I put PATCH_URI and what is the format? I suppose this should be someplace in the .cygport file? The README that is linked from the cygwin site doesn't mention it... Like SRC_URI, it is a string list variable to be defined early in the .cygport file. http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/cygport/trunk/README Do you have a link to the complete documentation perchance? It's not quite complete yet, but see /usr/share/doc/cygport/manual.html for the official documentation. Yaakov -- 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
Re: cygport/setup questions
Yaakov (Cygwin/X) yselkow...@users.sourceforge.net writes: It's not quite complete yet, but see /usr/share/doc/cygport/manual.html for the official documentation. Thanks, I'll have a look. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
Re: cygport/setup questions
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. 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. 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. 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. 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? 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. Yaakov -- 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
