Re: git: 0a0f7486413c - main - man: Build manpages for all architectures

On 25/11/2021 16:52, Fernando Apesteguía wrote:
> On Thu, Nov 25, 2021 at 3:37 PM Andriy Gapon <avg@freebsd.org> wrote:
>>
>> On 25/11/2021 16:31, Baptiste Daroussin wrote:
>>> On Thu, Nov 25, 2021 at 04:30:35PM +0200, Andriy Gapon wrote:
>>>> On 25/11/2021 16:23, Baptiste Daroussin wrote:
>>>>> On Thu, Nov 25, 2021 at 03:57:41PM +0200, Andriy Gapon wrote:
>>>>>> Looking at the output I got another thought: do we need architecture sub-dir
>>>>>> links at all now that we install manpages to a main directory?
>>>>>> Is there any benefit to having the same manpage in a directory (like man4)
>>>>>> and its immediate subdirectory (like man4/arm) ?
>>>>>>
>>>>> Hardlink not in the same directory is imho a fragile setup anyway, what if a
>>>>> user has different mount points here, the hardlink would be broken. while there
>>>>> is little chances someone is doing that, history told me people are doing weird
>>>>> things and if they haven't yet, they will soon.
>>>>>
>>>>> I continue to think this kind of links should be 1/ symlinks, 2/ relative
>>>>> symlinks if they are in a situation which can become a cross device issue.
>>>>
>>>> Yeah... but are they needed at all? :-)
>>>>
>>>> I mean, whichever way we install manpages they are always installed into
>>>> manX. I do not see a point / benefit of having another copy / link /
>>>> whatever in manX/arch.
>>>>
>>>> P.S.
>>>> Adding support for "MSYMLINKS" is not that hard.
>>>> But I'd rather remove some stuff than add some new stuff.
>>>>
>>>
>>> There I fully agree I don't see the point of the initial change in the first place :D
>>
>> Well, I do see the point of the change and I like it.
>> But I don't understand why / how  MANSUBDIR was / is useful.
>>
>> Perhaps people thought that hypothetically it would be a good idea if man foobar
>> on amd64 and sparc64 had different content...
>> But looks like it never happened and the idea (or strawman) is debatable too.
> 
> How about removing the MLINKS in every man4.${arch}/Makefile and doing
> something like this in the parent man4/Makefile?
> 
> diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile
> index dfef254bff5..46097319b06 100644
> --- a/share/man/man4/Makefile
> +++ b/share/man/man4/Makefile
> @@ -906,6 +906,9 @@ __arches=   ${MAN_ARCH}
>   .for __arch in ${__arches:O:u}
>   .if exists(${.CURDIR}/man4.${__arch})
>   SUBDIR+=       man4.${__arch}
> +.for __manpage in ${:!/bin/sh -c "/bin/ls -d ${.CURDIR}/man4.${__arch}*.4"!:E}
> +MLINKS+=       man4.${__arch}/${__manpage} ${__manpage}
> +.endfor
>   .endif
>   .endfor

I think that this should work.

> About keeping the arch-specific directories I don't have a strong
> opinion about it. It could be argued that it is a simple way to know
> which man pages are related to a certain architecture.

I am not sure if this is such an important thing.
There is a number of other ways to figure that out.
But it really should be documented in manpages themselves.

> In the case of
> the i386 most of the man pages have this information in the .Dt line:
> 
> [fernape@vm-current /usr/src/share/man/man4/man4.i386]$ grep Dt *.4
> CPU_ELAN.4:.Dt CPU_ELAN 4 i386
> apm.4:.Dt APM 4 i386
> ce.4:.Dt CE 4 i386
> cp.4:.Dt CP 4 i386
> glxiic.4:.Dt GLXIIC 4 i386
> glxsb.4:.Dt GLXSB 4 i386
> longrun.4:.Dt LONGRUN 4 i386
> npx.4:.Dt NPX 4 i386
> pae.4:.Dt PAE 4 i386
> pbio.4:.Dt PBIO 4 i386
> perfmon.4:.Dt PERFMON 4 i386
> pnp.4:.Dt PNP 4 i386
> pnpbios.4:.Dt PNPBIOS 4 i386
> sbni.4:.Dt SBNI 4 i386
> smapi.4:.Dt SMAPI 4 i386
> vpd.4:.Dt VPD 4 i386
> 
> But it is not the case for other man pages:
> 
> [fernape@vm-current /usr/src/share/man/man4/man4.powerpc]$ grep Dt *.4
> abtn.4:.Dt ABTN 4
> adb.4:.Dt ADB 4
> akbd.4:.Dt AKBD 4
> ams.4:.Dt AMS 4
> cuda.4:.Dt CUDA 4
> dtsec.4:.Dt DTSEC 4
> llan.4:.Dt LLAN 4
> ofw_console.4:.Dt OFW_CONSOLE 4 powerpc
> pmu.4:.Dt PMU 4
> powermac_nvram.4:.Dt POWERMAC_NVRAM 4 powerpc
> smu.4:.Dt SMU 4
> snd_ai2s.4:.Dt SND_AI2S 4
> snd_davbus.4:.Dt SND_DAVBUS 4
> tsec.4:.Dt TSEC 4



-- 
Andriy Gapon