On Fri, Dec 6, 2024 at 5:58 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On 12/6/24 11:15 AM, Mark Liam Brown wrote: > > On Fri, Dec 6, 2024 at 4:54 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > >> IMO, using a URL parser library might be better for us in the > >> long run (eg, more secure) than adding our own little > >> implementation. FedFS used liburiparser. > > > > Yeah, another library dependency for Debian? First you try to invade > > Debian with libxml2 via backdoor, and now you try to add liburlparser? > > At that point I would suggest that Debian just forks nfs-utils and > > yanks the whole libxml&liburlparser garbage out and replace it with a > > simple line parser. Does the same job and doesn't litter Debian > > This is a political screed rather than a technical concern. Nope. Stuffing the libxml2 garbage as dependiy to nfs-utils broke dracut in Debian and thus nfsroot support, and that is a REAL WORLD technical concern. > For one > thing, a fork certainly isn't needed to remove libxml2 or any other > library dependency -- all distributors carry local patches to such > packages. It is a concern that nfs-utils keep adding library dependencies for which there is no technical need. Junction support in nfs-utils could've used a simple tag=value format, instead a slow, resource-hungry and upgrade-antagonistic libxml2 was chosen. Real world users could not boot after that. So a fork of nfs-utils would jank out libxml2 and use a plain tag=value format for NFS junctions. So nay nay nay to more libraries, or keep it the liburiparser dep off by default. People who really want it can do an --enable-nfsurlsupportwithliburiparsergarbage. No one really needs exports and filenames with non-American characters anyway, the workaround is just mkdir /myjapanesefiles/, export that dir, and keep Japanese file names within that subtree. That would benefit people more because liburiparser.so.1630919828 would not be pulled in. Mark -- IT Infrastructure Consultant Windows, Linux
