On 2021/08/04 19:45, Ingo Schwarze wrote:
> Hi Andrew,
>
> Andrew Fresh wrote on Fri, Jul 30, 2021 at 05:34:40PM -0700:
> > On Sun, May 16, 2021 at 03:30:39PM -0700, Andrew Hewus Fresh wrote:
>
> >> There do appear to be some annoyances with still shared directories for
> >> man pages, in that if you install a CPAN module and then attempt to
> >> pkg_add it, it complains because "files already exist" in the man
> >> directory. We could separate the cpan man pages, or I think un-setting
> >> the site_lib man*dir will mean cpan won't instal them. I haven't yet
> >> tested that, but I'm not sure what would be best there.
>
> If i understand correctly, this is all about making installation of
> un-ported Perl modules work better and reducing clashes between doing
> that on the one hand and between package installation with pkg_add(1)
> on the other hand.
Correct. The specific problem that prompted this was people who had
installed something locally outside of ports - I think it was an updated
version of a core perl module - and made worse by pkg_add at the time
searching /usr/local/libdata/perl5/site_perl for modules and refusing
to run until the locally built module was removed.
pkg_add now uses "no lib ('/usr/local/libdata/perl5/site_perl')" so
it won't run into the same problem any longer, but most other perl
software is likely to still have the problem.
> Who will profit most from that? I guess very experienced Perl users
> and porters who play around a lot with many different Perl modules
> and with very large Perl programs, in particular when evaluating
> whether those large programs are worth porting. Not having manual
> pages installed for dependencies while trying to get a complicated
> program to work and while trying to understand it seems like a
> disservice to me. So "un-setting the site_lib man*dir" doesn't
> strike me as particularly convincing on first sight.
>
> I guess ordinary users are less likely to use this route, they are more
> likely to just use pkg_add(1). But if they do, for whatever reason,
> not getting manual pages is not good for them, either.
I think it's likely to be the other way round, at least people with more
experience of OpenBSD are more likely to start by making a port, partly
because they realise that installing modules from CPAN can cause
problems, partly to make it easier to clean up if needed.
I think ordinary users who need something that isn't ported are probably
more likely to pick it up from CPAN instead. (then, if they're more
experienced with Perl, they'll realise the cause of the "key mismatch"
error quickly and know what to do with it).
> So i think in the long term, installing those manual pages into their
> own manpath outside /ust/local/man/ would seem desirable to me.
> I'm not saying it needs to be done in the same commit; sorting that
> out can certainly be a later step.
I agree with all this.
> You suggest to make the sitelib directory versioned. Consequently,
> i guess that you want the following process to work:
>
> 1. install base and arbitrary numbers of packages
> 2. install lots of modules and programs from CPAN for evaluation
> 3. install the next Perl version outside base to figure out what
> needs to be done to ultimately move base to it
> 4. install various modules for the new Perl from step 3
> for testing purposes
>
> If i got that right, then the new man directory needs to be versioned
> just like the new sitelib directory, or the manual pages from steps 2
> and 4 will clash just like the libraries from steps 2 and 4 would.
> The price to pay, of course, is that you need to edit man.conf(5)
> for each new Perl you install. And not just you, the base system
> Perl maintainer, but all users installing stuff from CPAN.
I think perldoc would pick them up anyway - if so, users still have
an easy way to read the docs without editing man.conf.
> On the other hand, if working with two different Perl versions in
> parallel is not a requirement (for example because people do testing
> like in steps 3 and 4 on separate machines?), then i don't see why
> either the sitelib or the new man dir needs to be versioned at all,
> making everything simpler.
I think it's mostly to mitigate some user problems (at least, make it so
they are more obvious and less likely to need somebody more experienced
to point out what the problem is). On the one hand, that is already
reduced by the pkg_add change. But on the other, if it's simple enough
to reduce problems further then, as long as it doesn't get in the
way too much, why not..
