Mail Archives: cygwin/2012/03/14/15:33:56
"Yaakov (Cygwin/X)" <yselkowitz AT users DOT sourceforge DOT 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
- Raw text -