Re: git: 0a0f7486413c - main - man: Build manpages for all architectures
- Reply: Kyle Evans : "Re: git: 0a0f7486413c - main - man: Build manpages for all architectures"
- Reply: Andriy Gapon : "Re: git: 0a0f7486413c - main - man: Build manpages for all architectures"
- In reply to: Andriy Gapon : "Re: git: 0a0f7486413c - main - man: Build manpages for all architectures"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 25 Nov 2021 14:52:03 UTC
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 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. 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 Cheers. > > > -- > Andriy Gapon