perl5.8 fixup
Bradley Giesbrecht
brad at pixilla.com
Mon Mar 9 18:53:20 PDT 2009
On Mar 9, 2009, at 3:55 PM, Eric Hall wrote:
> On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote:
>> I have played around with my perl5.8 port and I have what appears to
>> me to be a solution to the path collision/registry issue.
>>
>> I modified my perl5.8 Portfile like so:
>>
>> configure.args-append -D man1dir='/opt/local/share/man/man1' -D
>> man1direxp='/opt/local/share/man/man1' -D man3dir='/opt/local/share/
>> man/man3' -D man3direxp='/opt/local/share/man/man3' -D
>> installman1dir='/opt/local/share/man/man1perl58' -D installman3dir='/
>> opt/local/share/man/man3perl58' -D installsiteman1dir='/opt/local/
>> share/man/man1perl58' -D installsiteman3dir='/opt/local/share/man/
>> man3perl58' -D installvendorman1dir='/opt/local/share/man/
>> man1perl58' -
>> D installvendorman3dir='/opt/local/share/man/man3perl58' -D
>> siteman1dir='/opt/local/share/man/man1perl58' -D siteman1direxp='/
>> opt/
>> local/share/man/man1perl58' -D siteman3dir='/opt/local/share/man/
>> man3perl58' -D siteman3direxp='/opt/local/share/man/man3perl58' -D
>> vendorman1dir='/opt/local/share/man/man1perl58' -D
>> vendorman1direxp='/
>> opt/local/share/man/man1perl58' -D vendorman3dir='/opt/local/share/
>> man/
>> man3perl58' -D vendorman3direxp='/opt/local/share/man/man3perl58'
>>
>> configure.args-append -D man1ext='1p58' -D man3ext='31p58'
>>
>
> Cool. I've been futzing with it too, with a simpler setup
> (haven't finished testing, but it looks like only the man1dir,
> siteman1dir, vendorman1dir are required - and their 3 complements
> of course).
I think the modules install their man pages to man3.
What I haven't been able to figure out yet is which man page man is
loading when there are more then one with the same name. The man
documentation suggests it will be the first match it finds so I think
we should be shooting for perl5.8 modules to be found after p5 module
man pages matching what you are doing with your inverted @INC.
My testing suggests to me this may be a drop in replacement. Edit
perl5.8 Portfile and bump revision and then port upgrade and your
perl5.8 and p5's are good to go without messing with all the other
installed software.
I haven't been able to confirm this but I think ideally only the
perl5.8 module mans should be moved and I think the p5 modules use the
perl5.8 compile settings if not overridden so finding exactly which
man paths need to changed is what I'm working on.
>> There may be more changes here then are necessary but I can confirm
>> that just modifying the man ext values did not do it as the p5
>> modules
>> also used this value.
>>
>> I bumped the revision number of my perl5.8 port and did an upgrade
>> and
>> I received no errors and with the minimal testing I've done I can now
>> install p5-cgi as an example without using -f.
>>
>> I am no way qualified to even test if this approach produces more
>> issues but so far I see non.
>>
>> Basically I added man1perl58 and man3perl58 man dirs after reading up
>> on man and seeing that other distros seem to add dirs to man. It
>> appears that man is able to find my man pages and the extension
>> change
>> was just for safety and it might we might be able to do away with
>> that
>> addition to configure.args.
>>
>> I added the configure.args as two appends so I could comment them out
>> easily to for testing.
>>
>> I hope someone with more perl5 knowledge then me can offer some
>> comments as to whether this approach will work without producing
>> other
>> problems.
>>
>> From what I can tell, this is something that can be done as a
>> revision upgrade to perl5.8 without changing anything else so port
>> upgrade perl5.8 solves the whole problem as relates to collisions.
>
> It won't solve everything, just the man page collisions.
>
> I've also inverted @INC in the what I'm testing, so far that's
> good as well (though again, I'm still testing things).
>
> Once I've gotten enough testing done to feel like its solid,
> I'll send out another note with the changes so others can test as
> well.
Agreed. I have been using the @INC env var you suggested earlier in
another thread I believe.
I like the idea presented in a recent post of having an /opt/local/etc/
profile file. If you execute the file it will add a line to
your .profile to source the file if it doesn't exist so new users can
just execute /opt/local/etc/profile and their home .profile is setup
for macports.
I'd also like something like /opt/local/ect/profile.d for things like
perl5.8 where /opt/local/ect/profile would source /opt/local/ect/
profile.d/* and perl5.8 would add /opt/local/ect/profile.d/perl5.8.
Then other ports like mysql5 could also add paths to their executables
into /opt/local/ect/profile.d/myslq5.
//Brad
More information about the macports-dev
mailing list